Re: ISDN massive packet drops while DVD burn/verify

[Karsten Keil <kkeil@suse.de>]

On Mon, May 05, 2003 at 05:32:49PM +0200, Stephan von Krawczynski wrote:
> On Mon, 5 May 2003 16:23:00 +0200
> Karsten Keil <kkeil@suse.de> wrote:
> 
> > Hi Stephan,
> 
> Hi Karsten,
> 
> long time no hear ;-)
> 

Yes.

> > > Sorry Alan, "been there, done that"
> > > I made ISDN work on just about anything that you would call an OS on
> > > sometimes quite ancient hardware (compared to nowadays), and I really
> > > cannot imagine that the combined (though sometimes confusing) efforts of
> > > you, Andre, Pavel, name-one on IDE made a dual 1.4 GHz PIII slower
> > > (responding) than a M68k 7,14 MHz with a polling IDE interface - which
> > > happens to be the slowest thing I ever did ISDN programming on
> > > _flawlessly_.
> > > 
> > 
> > No Alan and Kai are right.
> > 
> > The problem with the Infineon ISDN chips is that the fifos are small and so
> > IRQ latency is relativ critical. 32 or 64 bytes are only 4/8 ms, and if one
> > of these 32 Byte is dropped, the complete frame is lost. Modern ethernet
> > cards allways have fifos for multiple complete frames, so that such things
> > don't happen here.
> 
> I know the relatively small fifos. On the other hand compared to the ridiculous
> throughput of 8 kByte/sec (single channel) (which most people seem to ignore in
> this discussion), it is ok.

Again, the throughput doesn't matter so much.
The problem is latency and fifo size.
You lost a complete frame of 1500 Byte if one IRQ is missed and you need
about 46 IRQ per 1500 byte frame. So if you only miss 1% of RX IRQ, you
loose 33% of you troughput (every 3. frame).
On a High Speed Ethernet controller with 1% IRQ loss you don't see a effect,
since you loose also only 1%.
Thats why throughput doesn't matter in this case.

> 
> Let me simply ask back: is the IDE code in nowadays 2.4 kernel so bad, that a
> dual 1,4 GHz PIII cpu with 3 GB ram performs much worse than a 90 MHz P I with
> 64 MB and OS/2 on it???
> _My_ isdn drivers showed _no_ such problems under OS/2 and IDE load...
> 
> How did we manage to become that bad?

Its not so bad, the problem is how do you tune the system. If you prefer to
not interrupt the IDE transfers, which seems to be the default case, you
loose IRQ latency, which doesn't matter in much cases, but not on
this. You can tune it (hdparm work also with cdwriters, since
even if it use ide-scsi, the underlying driver is the ide driver.


> 
> > You can try to use HFC based ISDN cards (e.g. Conrad: ISDN TA 128K) the
> > fifos are much bigger (7.5kB) so at least 4 complete 1500 byte frames can be 
> > handled without segmentation. That increase the IRQ latency a lot (~900 ms).
> 
> I know HFC is nice. But that cannot mean ISAC/HSCX must have dropouts. You have
> to have long interrupt lock outs for such a behaviour, which cannot be intended
> at all.

Yes at least you must have 4+x ms interrupt lock outs, I didn't meassure it,
but reports show that hdparm -u1 helps in much cases. Note enabling IRQ
don't say that now the ISDN IRQ will handled, here maybe other IRQs with
higher priority which are served first and add extra latency.

This all don't say that here maybe also other problems around, but I have no
better explanation.

> 
> -- 
> Regards,
> Stephan

-- 
Karsten Keil
SuSE Labs
ISDN development