Hi Stephan,
On Sun, Apr 20, 2003 at 06:18:12PM +0200, Stephan von Krawczynski wrote:
> On 19 Apr 2003 23:01:32 +0100
> Alan Cox <[email protected]> wrote:
>
> > On Sad, 2003-04-19 at 18:38, Stephan von Krawczynski wrote:
> > > I don't buy that explanation. Reason is simple: during this all network
> > > connections work flawlessly, and they do have quite a lot of interrupts
> > > compared to ISDN. ISDN is so slow and has so few interrupts that it is
> > > quite unlikely in a SMP-beyond-GHz-limit box that you loose some. The
> > > ancient hardware days are long gone ...
> >
> > I'd suggest buying his explanation, because he's right. You are
> > confusing quantity and latency.
>
> 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.
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).
--
Karsten Keil
SuSE Labs
ISDN development
On Mon, 5 May 2003 16:23:00 +0200
Karsten Keil <[email protected]> wrote:
> Hi Stephan,
Hi Karsten,
long time no hear ;-)
> > 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.
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?
> 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.
--
Regards,
Stephan
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 <[email protected]> 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
On Mon, 5 May 2003 18:46:53 +0200
Karsten Keil <[email protected]> wrote:
> > 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 mean UDMA 2 does not make it (which I had in the test case)?
# hdparm -i /dev/hdc
/dev/hdc:
Model=SONY DVD RW DRU-500A, FwRev=2.0c, SerialNo=DA5B9D3D
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
Drive conforms to: device does not report version: 4 5 6
> This all don't say that here maybe also other problems around, but I have no
> better explanation.
Hm, this looks like the unresolved sleeping AVM Fritz2 syndrome to me: no idea
of what's really going on ...
--
Regards,
Stephan
On Mon, May 05, 2003 at 07:26:52PM +0200, Stephan von Krawczynski wrote:
> On Mon, 5 May 2003 18:46:53 +0200
> Karsten Keil <[email protected]> wrote:
>
> > > 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 mean UDMA 2 does not make it (which I had in the test case)?
>
> # hdparm -i /dev/hdc
>
> /dev/hdc:
>
> Model=SONY DVD RW DRU-500A, FwRev=2.0c, SerialNo=DA5B9D3D
> Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
> BuffType=unknown, BuffSize=0kB, MaxMultSect=0
> (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
> IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2
> UDMA modes: udma0 udma1 *udma2
> AdvancedPM=no
> Drive conforms to: device does not report version: 4 5 6
>
No the mode doesn't matter so much here, what give
hdparm -v /dev/hdc
> > This all don't say that here maybe also other problems around, but I have no
> > better explanation.
>
> Hm, this looks like the unresolved sleeping AVM Fritz2 syndrome to me: no idea
> of what's really going on ...
Hmm, don't remember this issue at the moment.
--
Karsten Keil
SuSE Labs
ISDN development
On Llu, 2003-05-05 at 16:32, Stephan von Krawczynski wrote:
> 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?
Our default behaviour in PIO mode is defensive to handle very old controller setups
that chew up disks when the disk gets ahead of the pio transfer.
On Llu, 2003-05-05 at 18:26, Stephan von Krawczynski wrote:
> You mean UDMA 2 does not make it (which I had in the test case)?
But is the transfer being done in UDMA mode ?
On 06 May 2003 11:53:32 +0100
Alan Cox <[email protected]> wrote:
> On Llu, 2003-05-05 at 18:26, Stephan von Krawczynski wrote:
> > You mean UDMA 2 does not make it (which I had in the test case)?
>
> But is the transfer being done in UDMA mode ?
# hdparm -v /dev/hdc
/dev/hdc:
HDIO_GET_MULTCOUNT failed: Invalid argument
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
BLKRAGET failed: Invalid argument
HDIO_GETGEO failed: Invalid argument
using_dma means it's using dma for transfer, right?
Regards,
Stephan
On Tue, May 06, 2003 at 02:39:02PM +0200, Stephan von Krawczynski wrote:
> On 06 May 2003 11:53:32 +0100
> Alan Cox <[email protected]> wrote:
>
> > On Llu, 2003-05-05 at 18:26, Stephan von Krawczynski wrote:
> > > You mean UDMA 2 does not make it (which I had in the test case)?
> >
> > But is the transfer being done in UDMA mode ?
>
>
> # hdparm -v /dev/hdc
>
> /dev/hdc:
> HDIO_GET_MULTCOUNT failed: Invalid argument
> IO_support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> BLKRAGET failed: Invalid argument
> HDIO_GETGEO failed: Invalid argument
>
>
> using_dma means it's using dma for transfer, right?
>
It should, but so far I know it cannot do every thing with
dma.
My writer use:
pingi2:~ # hdparm -v /dev/hdc
/dev/hdc:
HDIO_GET_MULTCOUNT failed: Input/output error
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
BLKRAGET failed: Input/output error
HDIO_GETGEO failed: Invalid argument
And I see no problems.
At least you can try hdparm -u1 (use a RW media).
--
Karsten Keil
SuSE Labs
ISDN development
On Maw, 2003-05-06 at 13:39, Stephan von Krawczynski wrote:
> HDIO_GET_MULTCOUNT failed: Invalid argument
> IO_support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> BLKRAGET failed: Invalid argument
> HDIO_GETGEO failed: Invalid argument
>
>
> using_dma means it's using dma for transfer, right?
Except for certain operations like audio cd ripping
On 6 May 2003, Alan Cox wrote:
> Except for certain operations like audio cd ripping
Burning audio cd's too, right?
I've noticed that burnfree gets triggered quite often while burning audio
cd's on my LiteOn LTR-48125W at 40x(maximum my cds will let me do).
Actually, speaking of that, I'm using burnfree under cdrecord 2.01a10.
Once in awhile I'll burn a cd and the red light turns to orange, indicating
burnproof has triggered on the drive.
Yet, at the end of the burn using -v, cdrecord will claim burnfree was
never needed even though it has triggered dozens of times.
Very weird.
Mike
On 06 May 2003 13:56:37 +0100
Alan Cox <[email protected]> wrote:
> On Maw, 2003-05-06 at 13:39, Stephan von Krawczynski wrote:
> > HDIO_GET_MULTCOUNT failed: Invalid argument
> > IO_support = 0 (default 16-bit)
> > unmaskirq = 0 (off)
> > using_dma = 1 (on)
> > keepsettings = 0 (off)
> > readonly = 0 (off)
> > BLKRAGET failed: Invalid argument
> > HDIO_GETGEO failed: Invalid argument
> >
> >
> > using_dma means it's using dma for transfer, right?
>
> Except for certain operations like audio cd ripping
Not used here.
We are using the DVDs (DVD-R) for data backups, some dozens a month.
And keep in mind: the problem occurs currently only while writing to DVD, not
while reading it.
Regards,
Stephan
Stephan von Krawczynski wrote:
> On 06 May 2003 13:56:37 +0100
> Alan Cox <[email protected]> wrote:
>
>
>>On Maw, 2003-05-06 at 13:39, Stephan von Krawczynski wrote:
>>
>>> HDIO_GET_MULTCOUNT failed: Invalid argument
>>> IO_support = 0 (default 16-bit)
>>> unmaskirq = 0 (off)
>>> using_dma = 1 (on)
>>> keepsettings = 0 (off)
>>> readonly = 0 (off)
>>> BLKRAGET failed: Invalid argument
>>> HDIO_GETGEO failed: Invalid argument
>>>
>>>
>>>using_dma means it's using dma for transfer, right?
>>
>>Except for certain operations like audio cd ripping
>
>
> Not used here.
> We are using the DVDs (DVD-R) for data backups, some dozens a month.
> And keep in mind: the problem occurs currently only while writing to DVD, not
> while reading it.
>
DVD writing seems to be problematic in other places too. I lose several
minutes of system time when I write a DVD. This is with SuSE 8.2 (SuSE
vendor kernel 2.4.20 based)
Wolfgang
> Regards,
> Stephan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>