I have an impertinent question.
I’m addicted to Windbg over 1394. It’s a much better and better
performing solution than any serial port connection. However, I have
often wondered why it isn’t faster than it is. I mean, 1394 debugging
is certainly faster than even a 230k baud serial port, but it is only
incrementally faster. Theoretically, it should be 2,000 times faster.
I’m debugging drivers for Media Center Edition, which means I not only
have my driver debug output, but DirectShow debug output, and MSVidCtl
debug output as well. I just did a boot where I had just about 300k
bytes of debug output before the desktop came up. It took well over a
minute for the output to come out, whereas it should have taken just a
few milliseconds.
Is it the windbg protocol? Does it require excessive round-trips?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
How long does ‘.dump /f’ take? On my 2-GB system, it takes about 2
minutes.
That said, try ctrl+d (ctrl+alt+d in windbg). It’ll turn on some
noisy spew, which would be interesting to see for the 300k transmission
during bootup. Specifically, you’ll be looking for errors, or the spew
right around a slowdown. That will help determine what type of issue
you’re seeing.
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, August 12, 2005 12:00 PM
To: Kernel Debugging Interest List
Subject: [windbg] 1394 Debugging
I have an impertinent question.
I’m addicted to Windbg over 1394. It’s a much better and better
performing solution than any serial port connection. However, I have
often wondered why it isn’t faster than it is. I mean, 1394 debugging
is certainly faster than even a 230k baud serial port, but it is only
incrementally faster. Theoretically, it should be 2,000 times faster.
I’m debugging drivers for Media Center Edition, which means I not only
have my driver debug output, but DirectShow debug output, and MSVidCtl
debug output as well. I just did a boot where I had just about 300k
bytes of debug output before the desktop came up. It took well over a
minute for the output to come out, whereas it should have taken just a
few milliseconds.
Is it the windbg protocol? Does it require excessive round-trips?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Jason Shay wrote:
How long does ‘.dump /f’ take? On my 2-GB system, it takes about 2
minutes.
One minute for half a gig. Hard to complain about that; the bottleneck
might actually be my disk
That said, try ctrl+d (ctrl+alt+d in windbg). It’ll turn on some
>noisy spew, which would be interesting to see for the 300k transmission
>during bootup. Specifically, you’ll be looking for errors, or the spew
>right around a slowdown. That will help determine what type of issue
>you’re seeing.
>
>
I’m not sure it’s really an “issue”, and it isn’t like there is a
particular “slowdown”. The debug print rate seems fairly constant the
whole time I’m connected. If I were really seeing 10 megabytes a
second, which is what the .dump gets, debug output should scroll way
faster than I can read them.
My assumption is that the protocol is a non-windowed two way exchange
(“I’m ready”, “here it comes”, “I got it”, “here comes some more”), and
that kind of thing is always slower than the theoretical max.
Do a “dd 80000000 L 4000”. On my setup, that dumps 65k bytes and takes
8 seconds.
I want to emphasize that I’m not complaining. I simply find this
interesting, and wondered if there was a reason.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.