diff options
author | B. Watson <yalhcru@gmail.com> | 2021-07-24 14:08:29 -0400 |
---|---|---|
committer | B. Watson <yalhcru@gmail.com> | 2021-07-24 14:08:29 -0400 |
commit | 5cc08ed2e9c465e0e8290410fc0a10e5737fc058 (patch) | |
tree | ac20a5b1f92cf07d7a69309b3a995ce4b83eb7c0 /README.txt | |
parent | f81125b285faa47273f699873fe49871123d0924 (diff) | |
download | slowbaud-5cc08ed2e9c465e0e8290410fc0a10e5737fc058.tar.gz |
Move notes to separate NOTES.txt, add CPU time display
Diffstat (limited to 'README.txt')
-rw-r--r-- | README.txt | 34 |
1 files changed, 1 insertions, 33 deletions
@@ -83,38 +83,6 @@ NOTES 10 to get bytes per second. This simulates "8-N-1": one start bit, 8 data bits, no parity, and 1 stop bit (total of 10 bits per byte). - The timing code works by calculating how long to sleep after each character - (in microseconds), but actually sleeping slightly less 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). - - 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 sig‐ - wait(). 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). 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 do this because - slowbaud is just a toy, and because the RT stuff tends to be unportable and - require elevated privileges (root, or something like setrtlimit or extended - filesystem attributes to manage capabilities). - - About the name... I'm aware that "baud" is not synonymous with bps. I just - think "slowbaud" sounds better than "slowbps", as a name. Anyway the stty com‐ - mand on both Linux and OSX misuses the term ("speed 38400 baud"), as well as - the man page for termios(3), so I'm in good company. - BUGS With -c, signals aren't handled gracefully. Window size changes (SIGWINCH) don't get propagated to the child process, and pressing ^C doesn't interrupt @@ -124,4 +92,4 @@ COPYRIGHT slowbaud is copyright 2021, B. Watson <yalhcru@gmail.com>. Released under the WTFPL. See http://www.wtfpl.net/txt/copying/ for details. -0.0.1 2021-07-23 SLOWBAUD(1) +0.0.1 2021-07-24 SLOWBAUD(1) |