2008/10/14 Roberto A. Foglietta <[EMAIL PROTECTED]>: > 2008/10/14 Denys Vlasenko <[EMAIL PROTECTED]>: >> On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote: >>> On Sunday 12 October 2008 23:48:22 Rob Landley wrote: >>> > Next time it reads a buffer, it starts with the last character of a cursor >>> > left sequence: capital D. Capital D is "delete to end of line", which it >>> > does. >>> > >>> > So basically, busybox vi is corrupting your data when you cursor around in >>> > a file on a loaded system. Wheee... >>> >>> Hmmm... I redid the readit() code to only read ahead when processing an >>> escape sequence. (This let me shrink the readahead buffer to 8 bytes, >>> actually 5 but with 32 bit alignment 8 makes more sense. Bloatcheck says I >>> shrunk the code by 17 bytes.) >> >> Disregard my previous patch, I just looked at your code and it's >> as good but it's smaller than mine, so let's use yours. >> >>> Unfortunately, this mitigated the problem a bit, but didn't actually _fix_ >>> it. >>> It happens less often, but I can still trigger it. >>> >>> I _think_ this is actually a qemu issue. The escape sequences are being >>> generated by the host Linux, which are then sent to the qemu process over a >>> virtual serial console, which breaks them down into individual bytes with an >>> interrupt for each. >>> >>> This means that the blocking we're depending on to parse escape sequences >>> doesn't work over a serial console. You _can get an escape character by >>> itself with poll saying there's no more data, and then on the next clock >>> cycle you can get a "[D". >>> >>> Hmmm... >>> >>> Ok, making poll wait 300 miliseconds before deciding there's no next >>> character >>> in a pending escape sequence seems to have fixed it. (At least I can't >>> reproduce the problem under qemu anymore.) >> >> Please document this next time, or someone else might come later >> and delete the timeout. I did this a few mins ago :( will fix it now. >> >> Did you try something smaller than 300ms? > > As far as I understood the problem: considering a 1200bps line, 120 > chars per second, 40 escape sequence per seconds, then the minimum > timeout should be at least 1/40 sec = 25 ms. This is for a fixed speed > line, considering an asynchronous data line with an average speed of > 1200bps and a bell curve variance of 25 ms then using a timeout of > 100ms would catch the 0.999936657516% of the escape sequences. > Enlarging the timeout to 150ms 0.999999998027%. Over 200ms should not > make any sense any more if the variance has been correctly estimated > in 25 ms. > > http://en.wikipedia.org/wiki/Normal_distribution >
Because the distribution for delays follows a poisson curve you should add 25ms to the timeout I previously estimated: 100 -> 125, 150 -> 175 and 200 -> 225. This because the after having wait for 25 ms (fixed speed line) the poisson curve could be fairly approximated with a gaussian curve. Ciao, -- /roberto _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
