From: Stephan von Krawczynski <skraw@ithnet.com>
To: Christian Vogel <vogel@skunk.physik.uni-erlangen.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: ISDN massive packet drops while DVD burn/verify
Date: Sat, 19 Apr 2003 22:23:48 +0200 [thread overview]
Message-ID: <20030419222348.0d899998.skraw@ithnet.com> (raw)
In-Reply-To: <20030419205000.A3541@skunk.physik.uni-erlangen.de>
On Sat, 19 Apr 2003 20:50:00 +0200
Christian Vogel <vogel@skunk.physik.uni-erlangen.de> wrote:
> Hi Stephan,
>
> On Sat, Apr 19, 2003 at 07:38:48PM +0200, Stephan von Krawczynski wrote:
> > > My best guess would be that IDE blocks IRQs for too long and hisax
> > > interrupts get lost. You could try whether hdparm -u1 helps, and a
> > > debugging log from the hisax driver may confirm over/underruns.
>
> > 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 would. At least try it. Network connections are not subject to smaller
> delays, ISDN on the other hand depends on a synchronous processing of the
> data (it's like a sync serial port after all...). It's not important how
> fast your CPU is if it's just doing nothing while waiting for your
> harddisk...
First: we are not talking about harddisks by any means.
Second: if it is doing _nothing_ while waiting for ide-whatever, then it is
presumably also not updating my mouse position or performing anything else
useful. This is _not_ the case here.
Third: a full-blown (1 channel) ISDN-download has around 8kBytes/sec of data.
The worst chipsets ever will create around 250 interrupts/sec for this (32 byte
fifo per hdlc-chunk). Don't count on the exact number, it may be some few more
than 250, but not a lot. This may have been a problem on very old boxes from
some years back, but for sure not on todays GHz monsters. You can only kill it
by completely braindead interrupt programming, which - I honor Alans' IDE stuff
quite a lot - I do not presume existing somewhere inside the current kernel.
Forth: There are parts in the ISDN code like:
static int
isdn_writebuf_stub(int drvidx, int chan, const u_char * buf, int len,
int user)
{
int ret;
int hl = dev->drv[drvidx]->interface->hl_hdrlen;
struct sk_buff *skb = alloc_skb(hl + len, GFP_ATOMIC);
if (!skb)
return 0;
Used here:
lock_kernel();
...
while (isdn_writebuf_stub(drvidx, chidx, buf, count, 1) != count)
interruptible_sleep_on(&dev->drv[drvidx]->snd_waitq[chidx]);
Which basically means we are looping around for some mem without telling anybody... or not?
This is probably not a very good example of what I mean, but nevertheless ...
> I would recommend doing /sbin/hdparm -u1 -c1 -d1 /dev/hda which makes
> all systems I know more performant and better responding.
You cannot issue that command to a DVD-writer used with ide-scsi.
>
> Chris
>
> --
> The code was willing,
> It considered your request,
> But the chips were weak.
> -- Barry L. Brumitt
>
Regards,
Stephan
next prev parent reply other threads:[~2003-04-19 20:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-16 13:12 ISDN massive packet drops while DVD burn/verify Stephan von Krawczynski
2003-04-18 14:25 ` Kai Germaschewski
2003-04-19 17:38 ` Stephan von Krawczynski
[not found] ` <20030419205000.A3541@skunk.physik.uni-erlangen.de>
2003-04-19 20:23 ` Stephan von Krawczynski [this message]
2003-04-19 22:01 ` Alan Cox
2003-04-20 16:18 ` Stephan von Krawczynski
2003-04-20 18:53 ` Alan Cox
2003-05-05 14:23 ` Karsten Keil
2003-05-05 15:32 ` Stephan von Krawczynski
2003-05-05 16:46 ` Karsten Keil
2003-05-05 17:26 ` Stephan von Krawczynski
2003-05-05 18:31 ` Karsten Keil
2003-05-06 10:53 ` Alan Cox
2003-05-06 12:39 ` Stephan von Krawczynski
2003-05-06 12:56 ` Alan Cox
2003-05-06 14:01 ` Stephan von Krawczynski
2003-05-06 16:46 ` Wolfgang Fritz
2003-05-06 14:13 ` Mike Dresser
2003-05-06 13:06 ` Karsten Keil
2003-05-06 9:52 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030419222348.0d899998.skraw@ithnet.com \
--to=skraw@ithnet.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vogel@skunk.physik.uni-erlangen.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).