linux-kernel - Re: Serial custom speed deprecated?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44F0A310.4010107@mauve.plus.com>
Date:	Sat, 26 Aug 2006 20:37:52 +0100
From:	Ian Stirling <ian.stirling@...ve.plus.com>
To:	linux@...izon.com
CC:	linux-kernel@...r.kernel.org
Subject: Re: Serial custom speed deprecated?

linux@...izon.com wrote:
>> Or we could just add a standardised extra set of speed ioctls, but then
>> we need to decide what occurs if I set the speed and then issue a
>> termios call - does it override or not.
> 
<snip>
> Alternatively, you could observe that asynchronous communications only
> requires agreement withing 5% between sender and receiver, so specifying
> a baud rate to much better than 1% is not too important.

To nitpick.
For a 10 bit long word, if the receiver syncs to within 1/8th of  the 
middle of a bit-time at the start, you've got 2/8th of a bit-time of 
disagreement possible, before you are likely to get errors, especially 
on limited slew-rate signals. (more modern chips will likely sample faster)
Or 3/80, or 2.5%. If the other side has made a similar calculation, then 
you should only really rely on 1%.
5% is the best possible case - that will in most circumstances cause errors.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/