Re: [U-Boot] RFC - How to speed up multiplexed input between serial and network?
On Wed, 29 Oct 2008 13:14:52 +0100 Wolfgang Denk [EMAIL PROTECTED] wrote: [big snip details of analysis] My suggestion is to make the multiplexing more intelligent instead of making the serial driver more complex. The nice thing with this is that you probably still get the same results (actually even better ones as the artificial 128 byte line lengt limit can be avoided), and the changes are only in the new code, i. e. users who do not need such I/O multiplexing will not be affected. I think it should be fairly simple to implement something similar to the VTIME feature for non-canonical reads in the Unix serial drivers (see man tcsetattr): - In idle mode, all configured input devices are polled in a round-robin manner (as it is done now). - As soon as a character is received on the serial line, a timestamp is taken. As you calculated, one character at 115 kbps takes about 100 us on the wire. Within a window of (for exmaple) 500 us (or about 5 character times) now polling of all other I/O ports will be skipped. I took a quick look at this idea, but I didn't try to implement all the fancy timestamp stuff, etc. Basically, I kept the pointer to the last device which had input and checked it first in tstc(). My testing was done on a sequoia at a baudrate of 115200. The sequoia is a fast board. Testing was done with combinations of stdin and stdout devices (serial and nc). I observed no performance improvements. I then looked more closely at the results of a rather simple case - stdin=serial and stdout=serial,nc. In this case the change mentioned above would have no effect since ther is only one stdin device. Doing a paste of an 80 character line resulted in 90% loss of input. With stdin=stdout=serial cutpaste worked with no character loss. The obvious conclusion is that the _output_ to nc was so slow that it caused the character loss. Thus, efforts to try to optimize the input at high baudrates in the multiplexing code itself it will not help due to the slow output. The suggestion to lower the baudrate seems like the most intelligent solution. --- Gary Jennejohn * DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] * ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC - How to speed up multiplexed input between serial and network?
Dear Bigler, Stefan, In message [EMAIL PROTECTED] you wrote: This should give you raw serial driver performacne while a serial data transfer is running, while keeping functionality for all other use cases. What do you think? First we need to have a good and accepted solution to reduce the time in NetLoop e.g. read only the env when changed. Then the polling is not anymore critical path. Hm... sorry, but I disagree. With my suggestion above, the time spent in NetLoop() does not matter any more at all. So no optimizations there will be needed to get your code working. Optimizing NetLoop() is a complex thing with global impact that will require a lot of testing. There is little chance to see this in mainline soon - at least not in the upcoming 2008.12 release. My suggestion however results in small code, and additionally this code affects only users of the new console multiplexing feature, but nobody else. Such a modification could go into mainline much faster. But I agree that it is a worthwile goal to optimize NetLoop() anyway. The main problem from my point of view is the echo of the received data to serial and also to nc. This is done now immediately, character by character and this takes time (more than we have). Sorry. I don't get it. It seems you bring up a new topic here. Less than 6 hours before this you wrote: The polling of the serial driver is too slow to get all characters. ... we added hooks to measure the time for tstc() execution. The measured time are: ... nc 15 Milliseconds. My interpretation was (and is) that it's the *input* processing which is your major concern. And I showed a way to solve this problem ( at least I think that my suggestion will solve it). Now you bring up a new topic - the time needed to output the characters. May be we should try and solve problems sequentially - if we throw all isses we see into one big pot we might not be able to swallow this. BTW: did you measure any times for the character output? Am I right when I say that between a read from character getc() until the next call of getc() we have 100 Microseconds to do all the required processing otherwise we lose data? On average, yes. The time for a single character might be longer (up to close to 200 us) assumimg we are fast enough then to catch the third char. All this assuming a console baudrate of 115 kbps. BTW - reducing the console baud rate would be a trivial way to avoid most of these issues ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC - How to speed up multiplexed input between serial and network?
Dear Denk Wolfgang, In message [EMAIL PROTECTED] you wrote: This should give you raw serial driver performacne while a serial data transfer is running, while keeping functionality for all other use cases. What do you think? First we need to have a good and accepted solution to reduce the time in NetLoop e.g. read only the env when changed. Then the polling is not anymore critical path. Hm... sorry, but I disagree. With my suggestion above, the time spent in NetLoop() does not matter any more at all. So no optimizations there will be needed to get your code working. If you know how to implement the behaviour like VTIME I'm fine, but I don't understand how it can work. Is it correct to say: To check if data is received at our nc we have run NetLoop(). If yes, one run cost me 15 Milliseconds, so 150 character are potentially lost on the serial. Of course when I'm on the serial I stay longer on the serial and read more. The main problem from my point of view is the echo of the received data to serial and also to nc. This is done now immediately, character by character and this takes time (more than we have). Sorry. I don't get it. It seems you bring up a new topic here. Less than 6 hours before this you wrote: The polling of the serial driver is too slow to get all characters. ... we added hooks to measure the time for tstc() execution. The measured time are: ... nc 15 Milliseconds. My interpretation was (and is) that it's the *input* processing which is your major concern. And I showed a way to solve this problem ( at least I think that my suggestion will solve it). Now you bring up a new topic - the time needed to output the characters. May be we should try and solve problems sequentially - if we throw all isses we see into one big pot we might not be able to swallow this. Sorry I did not tell you the full story (I also do not understand all). BTW: did you measure any times for the character output? What I know is, that reducing the time spend in the functions for nc by calling getenv() only when the env is changed is listed below: nc tstc() before 15 Milliseconds after 60 Microseconds nc getc() before 5 Microseconds after 5 Microseconds nc send_packet() before 90 Microseconds after 90 Microseconds For the receiving the real job is done in tstc(), getc() only take it from the input_buffer. The sending do not run the NetLoop() in steady state. This explains that only the tstc() gets faster. BTW - reducing the console baud rate would be a trivial way to avoid most of these issues ;-) Reducing the baud rate helps here the measurements (pasting a 200 character line) with 57600 6% of the characters are lost with 38400 0% of the characters are lost -- this would work Am I right when I say that between a read from character getc() until the next call of getc() we have 100 Microseconds to do all the required processing otherwise we lose data? On average, yes. The time for a single character might be longer (up to close to 200 us) assumimg we are fast enough then to catch the third char. All this assuming a console baudrate of 115 kbps. I agree with this when we assume that one character is received in the buffer/bd and 2 can be held in the HW-FIFO. When this would be the case then I should receive always the 3 first characters and then we have losses. But this is not the case we already loose the second. Do you have an explanation for this? Best regards, Stefan Bigler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
