Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins <andyparkins@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Thursday 2005 May 05 18:51, rich+ml@lclogic.com wrote:

> > Is it unreasonable to expect Linux to do a 200us turnaround?
>
> Assuming you have 2.6 kernel? HZ=1000 and you'll only get 1mS resolution

Thanks for your response.  You'll have to forgive me, I'm only vaguely 
familiar with the kernel internals.  I thought that because all of the work 
is being done in the kernel that the HZ value wouldn't have an effect?  In 
serial_core.c: uart_wait_until_sent() the character timeout is defined as

char_time = (port->timeout - HZ/50) / port->fifosize;
char_time = char_time / 5;

From this I guess that port->timeout is the estimated time for the whole 
transmit buffer, which is then divided by port->fifosize to make this a per 
character time which is then divided by five to ensure that the check for 
tx_empty() is done five times per character (the comments say this is to 
satisfy NIST-PCTS, whatever that is).  I'm not sure what the HZ/50 is for.

These times will all be significantly smaller than 1ms; if the value of HZ 
where going to affect this then why has the author bothered to calculate 
these times at all?  1ms would drown these other timeouts out.

Apologies if these are all stupid questions; as I say, I don't really know 
what I'm talking about. 


Andy

-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]