isoch firewire listen

NTDEV
1

Hi all,

First, is there a list dedicated solely to problems related to WDM firewire?

Well, anyway, here is a weird behavior I have noticed regarding isochronous
transfers on a WDM 1394 driver I’m working on. I have allocated resources
for listening on a channel and attached 2 quite big descriptors (but anyway
the size does not seem to have an effect here).

I receive callbacks every time a descriptor has been filled with incoming
data. Fine. But from time to time, I get those callbacks in the wrong
order.

More precisely: sometimes, I am notified that a buffer is filled but that
buffer does not correspond to the data I’m expecting (the next data block
count in a CIP header). It appears that some packets have been lost, but it
could happen, I can cope with that. But right after that, I get a callback
with the packets I thought were lost. So all the data is intact, it just
seems that the 1394 driver notified me in the wrong order. I have also
checked the sequential number (in the header of a packet when no quadlets
are stripped) and this has been inverted too.

I was wondering if someone else has ever experienced that kind of thing. If
you have a fix for that, a workaround or simply some insight as to why it
was implemented that way.

TIA! Mat

2

Mathieu,

I have also seen that myself where I got packets out of order, however I mainly
saw it happen on a multi-processor machine and not on a single-processor
machine. I did not find a fix for it myself (so please let me know if you
find one.) For me, dropping a packet is not desirable but is workable, I just
keep track of which packet I’m working on and if I get a previous packet that
I thought was lost (but came out of order) I just drop it as if it was corrupt.

Sorry for not being able to suggest a better solution, but at least you know
you are not the only person seeing this. Which OS/SP are you running this
on and is it a single or multi-process machine?

Regards,
Brad.

On Tue, Mar 11, 2003 at 09:52:33AM -0500, Mathieu Routhier wrote:

Hi all,

First, is there a list dedicated solely to problems related to WDM firewire?

Well, anyway, here is a weird behavior I have noticed regarding isochronous
transfers on a WDM 1394 driver I’m working on. I have allocated resources
for listening on a channel and attached 2 quite big descriptors (but anyway
the size does not seem to have an effect here).

I receive callbacks every time a descriptor has been filled with incoming
data. Fine. But from time to time, I get those callbacks in the wrong
order.

More precisely: sometimes, I am notified that a buffer is filled but that
buffer does not correspond to the data I’m expecting (the next data block
count in a CIP header). It appears that some packets have been lost, but it
could happen, I can cope with that. But right after that, I get a callback
with the packets I thought were lost. So all the data is intact, it just
seems that the 1394 driver notified me in the wrong order. I have also
checked the sequential number (in the header of a packet when no quadlets
are stripped) and this has been inverted too.

I was wondering if someone else has ever experienced that kind of thing. If
you have a fix for that, a workaround or simply some insight as to why it
was implemented that way.

TIA! Mat

3

Right now, I see it on a XP SP1 single-processor machine but I have seen
that on an XP SP1 multi-proc too and with different drivers. I haven’t
tried on other versions of windows yet.

Anyway, thank you for letting me know!

Mat

-----Original Message-----
From: Brad R [mailto:xxxxx@jedacite.dyndns.org]
Sent: Tuesday, March 11, 2003 1:15 PM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

Mathieu,

I have also seen that myself where I got packets out of order, however I
mainly
saw it happen on a multi-processor machine and not on a single-processor
machine. I did not find a fix for it myself (so please let me know if you
find one.) For me, dropping a packet is not desirable but is workable, I
just
keep track of which packet I’m working on and if I get a previous packet
that
I thought was lost (but came out of order) I just drop it as if it was
corrupt.

Sorry for not being able to suggest a better solution, but at least you know
you are not the only person seeing this. Which OS/SP are you running this
on and is it a single or multi-process machine?

Regards,
Brad.

On Tue, Mar 11, 2003 at 09:52:33AM -0500, Mathieu Routhier wrote:

Hi all,

First, is there a list dedicated solely to problems related to WDM
firewire?

Well, anyway, here is a weird behavior I have noticed regarding
isochronous
transfers on a WDM 1394 driver I’m working on. I have allocated resources
for listening on a channel and attached 2 quite big descriptors (but
anyway
the size does not seem to have an effect here).

I receive callbacks every time a descriptor has been filled with incoming
data. Fine. But from time to time, I get those callbacks in the wrong
order.

More precisely: sometimes, I am notified that a buffer is filled but that
buffer does not correspond to the data I’m expecting (the next data block
count in a CIP header). It appears that some packets have been lost, but
it
could happen, I can cope with that. But right after that, I get a
callback
with the packets I thought were lost. So all the data is intact, it just
seems that the 1394 driver notified me in the wrong order. I have also
checked the sequential number (in the header of a packet when no quadlets
are stripped) and this has been inverted too.

I was wondering if someone else has ever experienced that kind of thing.
If
you have a fix for that, a workaround or simply some insight as to why it
was implemented that way.

TIA! Mat

You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

You aren’t allocating the isoch resources with the RESOURCE_BUFFERS_CIRCULAR
flag set are you?

–
Bill McKenzie
Compuware Corporation
http://www.compuware.com/products/driverstudio/

“Mathieu Routhier” wrote in message
news:xxxxx@ntdev…
>
> Hi all,
>
> First, is there a list dedicated solely to problems related to WDM
firewire?
>
> Well, anyway, here is a weird behavior I have noticed regarding
isochronous
> transfers on a WDM 1394 driver I’m working on. I have allocated resources
> for listening on a channel and attached 2 quite big descriptors (but
anyway
> the size does not seem to have an effect here).
>
> I receive callbacks every time a descriptor has been filled with incoming
> data. Fine. But from time to time, I get those callbacks in the wrong
> order.
>
> More precisely: sometimes, I am notified that a buffer is filled but that
> buffer does not correspond to the data I’m expecting (the next data block
> count in a CIP header). It appears that some packets have been lost, but
it
> could happen, I can cope with that. But right after that, I get a
callback
> with the packets I thought were lost. So all the data is intact, it just
> seems that the 1394 driver notified me in the wrong order. I have also
> checked the sequential number (in the header of a packet when no quadlets
> are stripped) and this has been inverted too.
>
> I was wondering if someone else has ever experienced that kind of thing.
If
> you have a fix for that, a workaround or simply some insight as to why it
> was implemented that way.
>
> TIA! Mat
>
>
>

5

Well, yes.

Anything wrong? It improves speed quite a lot.

Mat

-----Original Message-----
From: Bill McKenzie [mailto:xxxxx@compuware.com]
Sent: Tuesday, March 11, 2003 3:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

You aren’t allocating the isoch resources with the RESOURCE_BUFFERS_CIRCULAR
flag set are you?

–
Bill McKenzie
Compuware Corporation
http://www.compuware.com/products/driverstudio/

“Mathieu Routhier” wrote in message
news:xxxxx@ntdev…
>
> Hi all,
>
> First, is there a list dedicated solely to problems related to WDM
firewire?
>
> Well, anyway, here is a weird behavior I have noticed regarding
isochronous
> transfers on a WDM 1394 driver I’m working on. I have allocated resources
> for listening on a channel and attached 2 quite big descriptors (but
anyway
> the size does not seem to have an effect here).
>
> I receive callbacks every time a descriptor has been filled with incoming
> data. Fine. But from time to time, I get those callbacks in the wrong
> order.
>
> More precisely: sometimes, I am notified that a buffer is filled but that
> buffer does not correspond to the data I’m expecting (the next data block
> count in a CIP header). It appears that some packets have been lost, but
it
> could happen, I can cope with that. But right after that, I get a
callback
> with the packets I thought were lost. So all the data is intact, it just
> seems that the 1394 driver notified me in the wrong order. I have also
> checked the sequential number (in the header of a packet when no quadlets
> are stripped) and this has been inverted too.
>
> I was wondering if someone else has ever experienced that kind of thing.
If
> you have a fix for that, a workaround or simply some insight as to why it
> was implemented that way.
>
> TIA! Mat
>
>
>

—
You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> Anything wrong?

Yep, Microsoft has confirmed that circular buffers is just flat broken in a
few different ways. I have seen exactly what you reported myself using
circular buffers. Callbacks were missed, hit out of order, it’s a mess.

Some folks from Microsoft have suggested not ever using this flag and always
handling the buffers in a linear fashion. There is no inherent reason why
using linear buffers and reattaching on the fly should not be every bit as
fast as circular buffers. In theory you should always have buffers
attached, so the time taken to detach and reattach buffers should not affect
your throughput unless you just haven’t attached enough buffers to begin
with.

I have done this for a digital video camera driver before (not using
streaming) and it worked well there. Not sure how fast is fast for you
though.

–
Bill McKenzie
Compuware Corporation
http://www.compuware.com/products/driverstudio/

“Mathieu Routhier” wrote in message
news:xxxxx@ntdev…
>
> Well, yes.
>
> Anything wrong? It improves speed quite a lot.
>
> Mat
>
> -----Original Message-----
> From: Bill McKenzie [mailto:xxxxx@compuware.com]
> Sent: Tuesday, March 11, 2003 3:53 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: isoch firewire listen
>
> You aren’t allocating the isoch resources with the
RESOURCE_BUFFERS_CIRCULAR
> flag set are you?
>
> –
> Bill McKenzie
> Compuware Corporation
> http://www.compuware.com/products/driverstudio/
>
>
>
> “Mathieu Routhier” wrote in message
> news:xxxxx@ntdev…
> >
> > Hi all,
> >
> > First, is there a list dedicated solely to problems related to WDM
> firewire?
> >
> > Well, anyway, here is a weird behavior I have noticed regarding
> isochronous
> > transfers on a WDM 1394 driver I’m working on. I have allocated
resources
> > for listening on a channel and attached 2 quite big descriptors (but
> anyway
> > the size does not seem to have an effect here).
> >
> > I receive callbacks every time a descriptor has been filled with
incoming
> > data. Fine. But from time to time, I get those callbacks in the wrong
> > order.
> >
> > More precisely: sometimes, I am notified that a buffer is filled but
that
> > buffer does not correspond to the data I’m expecting (the next data
block
> > count in a CIP header). It appears that some packets have been lost,
but
> it
> > could happen, I can cope with that. But right after that, I get a
> callback
> > with the packets I thought were lost. So all the data is intact, it
just
> > seems that the 1394 driver notified me in the wrong order. I have also
> > checked the sequential number (in the header of a packet when no
quadlets
> > are stripped) and this has been inverted too.
> >
> > I was wondering if someone else has ever experienced that kind of thing.
> If
> > you have a fix for that, a workaround or simply some insight as to why
it
> > was implemented that way.
> >
> > TIA! Mat
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@guillemot.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

7

Good God! Thank you for letting me know.

I just noticed that the flag is not in the DDK anymore (XP SP1 at least).
And more surprisingly, I got 0 hits on the whole MSDN searching for that
flag. Wouldn’t they have at least a KB article about that? They erased all
evidence! :wink:

I agree, if one reuses the buffers and reattach them immediately after being
called, there’s no reason why it should be slow.

Thank you so much!

Mat

-----Original Message-----
From: Bill McKenzie [mailto:xxxxx@compuware.com]
Sent: Tuesday, March 11, 2003 6:28 PM
To: NT Developers Interest List
Subject: [ntdev] Re: isoch firewire listen

Anything wrong?

Yep, Microsoft has confirmed that circular buffers is just flat broken in a
few different ways. I have seen exactly what you reported myself using
circular buffers. Callbacks were missed, hit out of order, it’s a mess.

Some folks from Microsoft have suggested not ever using this flag and always
handling the buffers in a linear fashion. There is no inherent reason why
using linear buffers and reattaching on the fly should not be every bit as
fast as circular buffers. In theory you should always have buffers
attached, so the time taken to detach and reattach buffers should not affect
your throughput unless you just haven’t attached enough buffers to begin
with.

I have done this for a digital video camera driver before (not using
streaming) and it worked well there. Not sure how fast is fast for you
though.

–
Bill McKenzie
Compuware Corporation
http://www.compuware.com/products/driverstudio/

“Mathieu Routhier” wrote in message
news:xxxxx@ntdev…
>
> Well, yes.
>
> Anything wrong? It improves speed quite a lot.
>
> Mat
>
> -----Original Message-----
> From: Bill McKenzie [mailto:xxxxx@compuware.com]
> Sent: Tuesday, March 11, 2003 3:53 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: isoch firewire listen
>
> You aren’t allocating the isoch resources with the
RESOURCE_BUFFERS_CIRCULAR
> flag set are you?
>
> –
> Bill McKenzie
> Compuware Corporation
> http://www.compuware.com/products/driverstudio/
>
>
>
> “Mathieu Routhier” wrote in message
> news:xxxxx@ntdev…
> >
> > Hi all,
> >
> > First, is there a list dedicated solely to problems related to WDM
> firewire?
> >
> > Well, anyway, here is a weird behavior I have noticed regarding
> isochronous
> > transfers on a WDM 1394 driver I’m working on. I have allocated
resources
> > for listening on a channel and attached 2 quite big descriptors (but
> anyway
> > the size does not seem to have an effect here).
> >
> > I receive callbacks every time a descriptor has been filled with
incoming
> > data. Fine. But from time to time, I get those callbacks in the wrong
> > order.
> >
> > More precisely: sometimes, I am notified that a buffer is filled but
that
> > buffer does not correspond to the data I’m expecting (the next data
block
> > count in a CIP header). It appears that some packets have been lost,
but
> it
> > could happen, I can cope with that. But right after that, I get a
> callback
> > with the packets I thought were lost. So all the data is intact, it
just
> > seems that the 1394 driver notified me in the wrong order. I have also
> > checked the sequential number (in the header of a packet when no
quadlets
> > are stripped) and this has been inverted too.
> >
> > I was wondering if someone else has ever experienced that kind of thing.
> If
> > you have a fix for that, a workaround or simply some insight as to why
it
> > was implemented that way.
> >
> > TIA! Mat
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@guillemot.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

—
You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com