🚀 go-pugleaf

In article <slrn6gljd1.q2.$julies/newsreply$@merp.demon.co.uk>,
	$julies/newsreply$@merp.demon.co.uk (Julie Brandon) writes:

> Okay, simple question!  Linux v2.0.33 & pppd 2.2.0f with a external
> modem using hardware handshaking, and 115K2 data rate...
> 
> How would I know if I am having serial overruns (i.e. not guessing
> from transfer speeds or pauses but actually *know*)?  
> 
> I'm trying to get our system flowing nicely under ppp, but I can't
> really tell whether or not I'm loosing out due to overruns.

Surely ifconfig reports serial overruns? If you don't trust ifconfig,
try downloading ftp.d.c.u/pub/test/regularfile. Assuming Demon's
machine and network are working properly, which has been known on
occasion, you should get 11 KB/sec download. Watch the RxD LED -
it will be on solidly. A damaged packet or two will show. Using
the hash option on the ftp client also gives a good indication of
pauses.


-- 
Richard Lamont
richard@stonix.demon.co.uk
http://www.stonix.demon.co.uk/

On 14 Mar 1998 22:13:29 GMT, Richard Lamont did spake:
>Surely ifconfig reports serial overruns?
Didn't know - do now.  *8-)

> If you don't trust ifconfig,
>try downloading ftp.d.c.u/pub/test/regularfile. Assuming Demon's
>machine and network are working properly, which has been known on

Thanks for the info.  Last time I tried this, Demon's end was ****. 
*8-(  Will do again though.

Thanks again.

Ta-ra,
  Julie.

-- 
*** IMPORTANT: If replying, leave e-mail address as is, it's correct! ***
"Here's a pin and here's a pingle, porcupines are always single,
 poor ol' 'pines they mustn't mingle, pingle pangle pingle."
[singing] Marvellous Mouse Organ Mice (Bagpuss: 1970s UK Children's TV)

In article <6eeve9$6l@stonix.demon.co.uk>,
Richard Lamont <richard@stonix.demon.co.uk> wrote:
>
>Surely ifconfig reports serial overruns?

It claims to, but it doesn't. I think this is because it's operating at
the wrong level. After all, it's designed to report overruns from Ethernet
cards and so forth, where the card can deliver data into Linux's internal
buffers far faster than the software can deal with it; here, the problem
is getting the data into Linux's buffers in the first place.

I think it's reporting overflows of those internal buffers (is it the TTY
flip buffer, or the TCP fragment reassembly queue? I've never quite worked
it out), not of the tiny FIFO inside the UART.

The easiest way to spot serial overflows is to not use irqtune and try
doing something that slams the disk at the same time as ftping something.
If the ftp transfer stops off dead when the disk access starts, you've got
overruns.[1]

[1] A tool like Andrew Bishop's ProcMeter (from
    http://www.gedanken.demon.co.uk/) is damn useful for reporting packet
    receive rates and interrupt levels - both of which tend to shadow
    each other fairly closely when heavy serial comm is going on.

-- 
`Oooo!  Saint Malcolm preserve us!  This is heresy.'

In article <slrn6go6pl.b4e.$julies/newsreply$@merp.demon.co.uk>,
	$julies/newsreply$@merp.demon.co.uk (Julie Brandon) writes:
> On 14 Mar 1998 22:13:29 GMT, Richard Lamont did spake:
> 
>> If you don't trust ifconfig,
>>try downloading ftp.d.c.u/pub/test/regularfile. Assuming Demon's
>>machine and network are working properly, which has been known on
> 
> Thanks for the info.  Last time I tried this, Demon's end was ****. 
> *8-(  Will do again though.

Last time I tried it, it was OK. I've just tried it again, and
Demon's end was, as you put it, ****. 


-- 
Richard Lamont
richard@stonix.demon.co.uk
http://www.stonix.demon.co.uk/

Nix <$eri$@esperi.demon.co.uk> writes:

> The easiest way to spot serial overflows is to not use irqtune and try
> doing something that slams the disk at the same time as ftping something.

My memory may be faulty, but I believe that the kernel complains about
serial overruns in the kernel log (wherever that ends up on your
system).

-- 
Mark Brown  mailto:broonie@tardis.ed.ac.uk   (Trying to avoid grumpiness)
            http://www.tardis.ed.ac.uk/~broonie/
EUFS        http://www.ed.ac.uk/~filmsoc/

On 15 Mar 1998 03:07:19 -0000, Nix did spake:
>The easiest way to spot serial overflows is to not use irqtune and try
>doing something that slams the disk at the same time as ftping something.
>If the ftp transfer stops off dead when the disk access starts, you've got
>overruns.[1]

A bit of a haphazard guessing way to do it, surely?  *8-(  Not to
mention the very real problem that we only get the overruns in *one*
situation -- transfers above 9000cps + related disk accesses (not
other general disc accesses).  Below that, the computer can do what
it darned well likes.

Ta-ra,
  Julie.

-- 
*** IMPORTANT: If replying, leave e-mail address as is, it's correct! ***
"Here's a pin and here's a pingle, porcupines are always single,
 poor ol' 'pines they mustn't mingle, pingle pangle pingle."
[singing] Marvellous Mouse Organ Mice (Bagpuss: 1970s UK Children's TV)

If your serial port line discipline is "normal tty", then this
happens:-

/* linux/drivers/char/n_tty.c 
 */
static inline void n_tty_receive_overrun(struct tty_struct *tty)
{
	char buf[64];

	tty->num_overrun++;
	if (tty->overrun_time < (jiffies - HZ)) {
		printk("%s: %d input overrun(s)\n", _tty_name(tty, buf),
		       tty->num_overrun);
		tty->overrun_time = jiffies;
		tty->num_overrun = 0;
	}
}




For PPP, you may or may not get this warning (linux/drivers/net/ppp.c):-

	if (ppp->toss) {
		if (ppp->flags & SC_DEBUG)
			printk (KERN_WARNING
				"ppp_toss: tossing frame, reason = %d\n",
				ppp->toss);
		ppp->stats.ppp_ierrors++;
		return 0;
	}
Look for reason 4 (TTY_OVERRUN from serial.h)

In article <6ehi6s$6va@stonix.demon.co.uk>,
	richard@stonix.demon.co.uk (Richard Lamont) writes:
> In article <slrn6go6pl.b4e.$julies/newsreply$@merp.demon.co.uk>,
> 	$julies/newsreply$@merp.demon.co.uk (Julie Brandon) writes:
>> On 14 Mar 1998 22:13:29 GMT, Richard Lamont did spake:
>> 
>>> If you don't trust ifconfig,
>>>try downloading ftp.d.c.u/pub/test/regularfile. Assuming Demon's
>>>machine and network are working properly, which has been known on
>> 
>> Thanks for the info.  Last time I tried this, Demon's end was ****. 
>> *8-(  Will do again though.
> 
> Last time I tried it, it was OK. I've just tried it again, and
> Demon's end was, as you put it, ****. 

I tried it this morning, when there were only 8 anonymous demon
users, and it worked fine. One thing I forgot is that you need to
use emptyfile4 so that tcp can get up to speed. With that I got
11KB/sec and no pauses at all on each of five consecutive attempts.
On the first two nothing else was happening on machine, on the last
three I used knews and netscape to rattle the disk. No change.

BTW I still haven't bothered with irqtune [ ;-) ], but my modem
port is on IRQ 2/9, which has fairly high priority by default IIRC.


-- 
Richard Lamont
richard@stonix.demon.co.uk
http://www.stonix.demon.co.uk/