diff options
Diffstat (limited to 'slowbaud.rst')
| -rw-r--r-- | slowbaud.rst | 21 |
1 files changed, 12 insertions, 9 deletions
diff --git a/slowbaud.rst b/slowbaud.rst index e270df7..bc6eb5a 100644 --- a/slowbaud.rst +++ b/slowbaud.rst @@ -46,7 +46,7 @@ interactive command in a pseudo-tty (the **-c** option). The *<bits-per-sec>* argument is optional. If it's not given, the bit rate will be set from **SLOWBAUD_BPS** in the environment, or a -built-in default of 2400 if not set. +built-in default of 2400 if that's not set. OPTIONS ======= @@ -110,11 +110,8 @@ With **-b**, exit status is 0, unless something catastrophic happened NOTES ===== -Timing accuracy depends on your OS, kernel config (HZ and/or NO_HZ -on Linux), and system load. No "fancy" techniques like realtime -scheduling or hardware event timers are used. At bitrates up to 57600, -on a typical unloaded Linux system, the timing should be at least -99.7% accurate. +The timing inaccuracy will almost always result in the bitrate +being slightly too slow. We can't really insert a delay between the bits of a byte, since I/O is done with byte granularity. For calculation purposes, @@ -128,15 +125,21 @@ than that, then busy-waiting until the rest of the interval expires. At slower bitrates, this works well, and the CPU overhead is barely noticeable (at least on reasonably fast modern systems). -The timing inaccuracy will almost always result in the bitrate -being slightly too slow. +Timing accuracy depends on your OS, kernel config (HZ and/or NO_HZ +on Linux), and system load. Also on the amount of data, since the +timing loop is self-regulating (the first few bytes will have less +accurate timing than later ones). No "fancy" techniques like realtime +scheduling or hardware event timers are used. At bitrates up to +115200, on an unloaded Linux system, the timing should be at least +99.9% accurate. At higher bitrates, accuracy will decrease. Timing is more accurate on Linux than OSX. It's done with getitimer() and sigwait(). This works out to be slightly more accurate than using usleep() on both Linux and OSX. It would be possible to use the realtime timer_create() and clock_gettime() API on Linux, for possibly even better accuracy, but OSX doesn't have these (and I want to be -portable). +portable). On an unloaded OSX system, the accuracy gets steadily worse +as you go above 57600bps. There's also more CPU overhead on OSX. If this were a truly useful application, it would be worth trying to increase accuracy further, with realtime process scheduling. I didn't |