IEEE 1394 for Linux

Damien Douxchamps wrote:
> Hi all,
> 
> I'd like to estimate the load of a set of 1394 cameras on the bus in
> order to warn users when saturation is near. Does someone know how to do
> this? Or maybe briefly tell me what are the constrains governing the bus
> load? I'm a bit confused about how to relate packets, cycles, devices,
> bandwidth,...

You could just read out the contents of the BANDWIDTH_AVAILABLE 
register.  It is offset 0xfffff0000220 at the IRM node.  The contents of 
this register gives the amount of remaining bandwidth on the bus, 
measured in bandwith units.  A bandwidth unit is the time it takes to 
send a quadlet at S1600 - for example, sending 11 quadlets at S400 
requires 11 * 4 bandwidth units.  Of course, this only works if the 
applications that initiate isochronous streams allocate bandwidth as 
required.

Initially 4915 bandwith units are available: 1600 Mbit/s gives 6144 
quadlets/cycle (1600 Mbit/s * 125 us/cycle = 6144 quadlets/cycle), but 
only 80% of those can be reserved for isochronous traffic, 80% of 6144 = 
4915.

Kristian

Hi Kristian,

On Mon, 2003-12-22 at 00:17, Kristian H=F8gsberg wrote:
> Damien Douxchamps wrote:
> > Hi all,
> >=20
> > I'd like to estimate the load of a set of 1394 cameras on the bus in
> > order to warn users when saturation is near. Does someone know how to=
 do
> > this? Or maybe briefly tell me what are the constrains governing the =
bus
> > load? I'm a bit confused about how to relate packets, cycles, devices=
,
> > bandwidth,...
>=20
> You could just read out the contents of the BANDWIDTH_AVAILABLE=20
> register.  It is offset 0xfffff0000220 at the IRM node.  The contents o=
f=20
> this register gives the amount of remaining bandwidth on the bus,=20
> measured in bandwith units.  A bandwidth unit is the time it takes to=20
> send a quadlet at S1600 - for example, sending 11 quadlets at S400=20
> requires 11 * 4 bandwidth units.  Of course, this only works if the=20
> applications that initiate isochronous streams allocate bandwidth as=20
> required.

Interesting way to do it, but the IRM keeps its 0x1333 (4915) value at
all times...?

> Initially 4915 bandwith units are available: 1600 Mbit/s gives 6144=20
> quadlets/cycle (1600 Mbit/s * 125 us/cycle =3D 6144 quadlets/cycle), bu=
t=20
> only 80% of those can be reserved for isochronous traffic, 80% of 6144 =
=3D=20
> 4915.

That info is interesting. Someone wrote in libdc that it was possible to
calculate the camera framerate when using Format_7. Without going into
the details, it means it is possible to get the framerate (and thus the
busload) with only this information:

- the packet size (example: 3440 bytes)
- the image size  (example: 2755440 bytes)
- the bus speed (400Mb/s)
- the '4915' units limit.

The only thing I know is that the relationship is more or less linear
(if there is one at all) because I measure the following:

pkt size	pkt number/frame	framerate (rough approx)
3440 b		801			8.92
2580 b		1068			4.42
1720 b		1602			4.42
860  b		3204			2.24

I must be missing something. Any idea?

Thank you,

Damien

--=20
  _    Damien Douxchamps
 (=B0-   PhD Student / Research Assistant
 //\   Image Processing Group, Telecom Laboratory, UCL, Belgium
 V_/_  http://www.tele.ucl.ac.be/MEMBERS/Douxchamps_Damien_e.html

Damien Douxchamps wrote:
> Hi Kristian,
> 
> On Mon, 2003-12-22 at 00:17, Kristian Høgsberg wrote:
> 
>>Damien Douxchamps wrote:
>>
>>>Hi all,
>>>
>>>I'd like to estimate the load of a set of 1394 cameras on the bus in
>>>order to warn users when saturation is near. Does someone know how to do
>>>this? Or maybe briefly tell me what are the constrains governing the bus
>>>load? I'm a bit confused about how to relate packets, cycles, devices,
>>>bandwidth,...
>>
>>You could just read out the contents of the BANDWIDTH_AVAILABLE 
>>register.  It is offset 0xfffff0000220 at the IRM node.  The contents of 
>>this register gives the amount of remaining bandwidth on the bus, 
>>measured in bandwith units.  A bandwidth unit is the time it takes to 
>>send a quadlet at S1600 - for example, sending 11 quadlets at S400 
>>requires 11 * 4 bandwidth units.  Of course, this only works if the 
>>applications that initiate isochronous streams allocate bandwidth as 
>>required.
> 
> Interesting way to do it, but the IRM keeps its 0x1333 (4915) value at
> all times...?

The BANDWIDTH_AVAILABLE register isn't updated automatically; it is a
requirement that applications allocate necessary bandwidth prior to
initiating isochronous traffic.  This is done by performing a
compare-swap lock transaction against the IRM: 1) read out the contents
of the BANDWIDTH_AVAILABLE register, 2) compute new value for the
register by subtracting desired amount of bandwidth, 3) send
compare-swap lock transaction to IRM to update value, 4) verify that the
transcation succeeded and that the returned old value equals the value
originally read from the IRM.  If all this succeeds, you have set aside
the required bandwith and can start streaming (provided you have
allocated an isochronous channel).  When you have finished streaming you
deallocate the bandwith in the same way.

When all streaming applications obey this protocol, the
BANDWIDTH_AVAILABLE will reflect the remaining bandwidth on the bus at
any time.

>>Initially 4915 bandwith units are available: 1600 Mbit/s gives 6144 
>>quadlets/cycle (1600 Mbit/s * 125 us/cycle = 6144 quadlets/cycle), but 
>>only 80% of those can be reserved for isochronous traffic, 80% of 6144 = 
>>4915.
> 
> That info is interesting. Someone wrote in libdc that it was possible to
> calculate the camera framerate when using Format_7. Without going into
> the details, it means it is possible to get the framerate (and thus the
> busload) with only this information:
> 
> - the packet size (example: 3440 bytes)
> - the image size  (example: 2755440 bytes)
> - the bus speed (400Mb/s)
> - the '4915' units limit.

The only things that matter for calculating the bus load is the maximum
possible isochronous packet size and the transmission speed.  I'm not
familiar with Format_7, but if the packet payload is 3440 bytes then the
packet size is 430 quadlets + 3 quadlets (isochronous header + 2 CRC32s)
= 433 quadlets. At S400, that amounts to 4 * 433 = 1732 bandwidth units,
which you must allocate from the IRM using the mechanism described above.

Kristian

Hi Kristian,

On Mon, 2003-12-22 at 16:57, Kristian H=F8gsberg wrote:
> >>You could just read out the contents of the BANDWIDTH_AVAILABLE=20
> >>register.  It is offset 0xfffff0000220 at the IRM node.  The contents=
 of=20
> >>this register gives the amount of remaining bandwidth on the bus,=20
> >>measured in bandwith units.  A bandwidth unit is the time it takes to=
=20
> >>send a quadlet at S1600 - for example, sending 11 quadlets at S400=20
> >>requires 11 * 4 bandwidth units.  Of course, this only works if the=20
> >>applications that initiate isochronous streams allocate bandwidth as=20
> >>required.
> >=20
> > Interesting way to do it, but the IRM keeps its 0x1333 (4915) value a=
t
> > all times...?
>=20
> The BANDWIDTH_AVAILABLE register isn't updated automatically; it is a
> requirement that applications allocate necessary bandwidth prior to
> initiating isochronous traffic.  This is done by performing a
> compare-swap lock transaction against the IRM: 1) read out the contents
> of the BANDWIDTH_AVAILABLE register, 2) compute new value for the
> register by subtracting desired amount of bandwidth, 3) send
> compare-swap lock transaction to IRM to update value, 4) verify that th=
e
> transcation succeeded and that the returned old value equals the value
> originally read from the IRM.  If all this succeeds, you have set aside
> the required bandwith and can start streaming (provided you have
> allocated an isochronous channel).  When you have finished streaming yo=
u
> deallocate the bandwith in the same way.
>=20
> When all streaming applications obey this protocol, the
> BANDWIDTH_AVAILABLE will reflect the remaining bandwidth on the bus at
> any time.

OK, well that's something we'll have to add to libdc1394...

> The only things that matter for calculating the bus load is the maximum
> possible isochronous packet size and the transmission speed.  I'm not
> familiar with Format_7, but if the packet payload is 3440 bytes then th=
e
> packet size is 430 quadlets + 3 quadlets (isochronous header + 2 CRC32s=
)
> =3D 433 quadlets. At S400, that amounts to 4 * 433 =3D 1732 bandwidth u=
nits,
> which you must allocate from the IRM using the mechanism described abov=
e.

<newbie>

1) I guess the size is 860+3, not 430+3 (3440/4=3D860). Right? ;-)

2) Is it true that if I start an isochronous transmission the device
must send a packet at every 125us cycle? Or it just _might_ send a
packet so I have to book the whole bandwidth anyway?

</newbie>

Damien

--=20
  _    Damien Douxchamps
 (=B0-   PhD Student / Research Assistant
 //\   Image Processing Group, Telecom Laboratory, UCL, Belgium
 V_/_  http://www.tele.ucl.ac.be/MEMBERS/Douxchamps_Damien_e.html

On Mon, 2003-12-22 at 11:48, Damien Douxchamps wrote:
> Hi Kristian,
>=20
> On Mon, 2003-12-22 at 16:57, Kristian H=F8gsberg wrote:
> > The BANDWIDTH_AVAILABLE register isn't updated automatically; it is a
> > requirement that applications allocate necessary bandwidth prior to
> > initiating isochronous traffic. =20
[...]=20
> > When all streaming applications obey this protocol, the
> > BANDWIDTH_AVAILABLE will reflect the remaining bandwidth on the bus at
> > any time.
>=20
> OK, well that's something we'll have to add to libdc1394...

hold on now! Note, Kristian's very important words "When all streaming
applications obey this protocol." Usually, as Kristian alluded to in
another message, the transmitter allocates bandwidth. When I was working
on dv1394d, I tried to check and set this register because my
application is a transmitter (or at least performing IEC 61883-1
Connection Management Procedures), and we were dealing with multiple
channels of iso comms. DV devices are typically both receivers and
transmitters. However, I noticed some devices allocating bandwidth when
not actively transmitting. We can set the transmit vs receive mode of
the device with some FCP async transactions, but even though they were
set to receive, some still did not relinquish bandwidth.

Therefore, is it the role of libdc1394 to allocate bandwidth when it
tells a camera to transmit? What if, despite the experience on your
camera, a different model camera does allocate bandwidth? I do not think
there is a reliable way to determine this. Therefore, if libdc1394
allocates bandwidth, then more bandwidth is allocated than actually in
use. Or does IIDC spec dictate that camera implementors not allocate
bandwidth with IRM?

+-DRD-+

Damien Douxchamps wrote:
> Hi Kristian,
>=20
> On Mon, 2003-12-22 at 16:57, Kristian H=F8gsberg wrote:
>=20
>>>>You could just read out the contents of the BANDWIDTH_AVAILABLE=20
>>>>register.  It is offset 0xfffff0000220 at the IRM node.  The contents=
 of=20
>>>>this register gives the amount of remaining bandwidth on the bus,=20
>>>>measured in bandwith units.  A bandwidth unit is the time it takes to=
=20
>>>>send a quadlet at S1600 - for example, sending 11 quadlets at S400=20
>>>>requires 11 * 4 bandwidth units.  Of course, this only works if the=20
>>>>applications that initiate isochronous streams allocate bandwidth as=20
>>>>required.
>>>
>>>Interesting way to do it, but the IRM keeps its 0x1333 (4915) value at
>>>all times...?
>>
>>The BANDWIDTH_AVAILABLE register isn't updated automatically; it is a
>>requirement that applications allocate necessary bandwidth prior to
>>initiating isochronous traffic.  This is done by performing a
>>compare-swap lock transaction against the IRM: 1) read out the contents
>>of the BANDWIDTH_AVAILABLE register, 2) compute new value for the
>>register by subtracting desired amount of bandwidth, 3) send
>>compare-swap lock transaction to IRM to update value, 4) verify that th=
e
>>transcation succeeded and that the returned old value equals the value
>>originally read from the IRM.  If all this succeeds, you have set aside
>>the required bandwith and can start streaming (provided you have
>>allocated an isochronous channel).  When you have finished streaming yo=
u
>>deallocate the bandwith in the same way.
>>
>>When all streaming applications obey this protocol, the
>>BANDWIDTH_AVAILABLE will reflect the remaining bandwidth on the bus at
>>any time.
>=20
>=20
> OK, well that's something we'll have to add to libdc1394...

Yeah, it's not too complicated, raw1394 has a function to get the IRM=20
node id, and then it's just a read quadlet call and a lock call.  One=20
thing I didn't mention is that on bus resets the BANDWIDTH_AVAILABLE=20
register is reset to 0x1333, so you should reestablish the allocation=20
from a bus reset callback handler.

>>The only things that matter for calculating the bus load is the maximum
>>possible isochronous packet size and the transmission speed.  I'm not
>>familiar with Format_7, but if the packet payload is 3440 bytes then th=
e
>>packet size is 430 quadlets + 3 quadlets (isochronous header + 2 CRC32s=
)
>>=3D 433 quadlets. At S400, that amounts to 4 * 433 =3D 1732 bandwidth u=
nits,
>>which you must allocate from the IRM using the mechanism described abov=
e.
>=20
> <newbie>
>=20
> 1) I guess the size is 860+3, not 430+3 (3440/4=3D860). Right? ;-)

Uh, right :-)

> 2) Is it true that if I start an isochronous transmission the device
> must send a packet at every 125us cycle? Or it just _might_ send a
> packet so I have to book the whole bandwidth anyway?

True, the device must send a packet every isochronous cycle.  If it has=20
no data to send it can send an empty packet (ie. only headers and CRCs),=20
but it must transmit every cycle.  The bandwidth allocated must=20
correspond to the largest packet it will transmit, so when the device=20
transmits an empty packet, that bandwidth is essentially wasted.

Kristian

Dan Dennedy wrote:
> On Mon, 2003-12-22 at 11:48, Damien Douxchamps wrote:
>=20
>> Hi Kristian,
>>=20
>> On Mon, 2003-12-22 at 16:57, Kristian H=F8gsberg wrote:
>>=20
>>> The BANDWIDTH_AVAILABLE register isn't updated automatically; it=20
>>> is a requirement that applications allocate necessary bandwidth=20
>>> prior to initiating isochronous traffic.
>=20
> [...]
>=20
>>> When all streaming applications obey this protocol, the=20
>>> BANDWIDTH_AVAILABLE will reflect the remaining bandwidth on the=20
>>> bus at any time.
>>=20
>> OK, well that's something we'll have to add to libdc1394...
>=20
>=20
> hold on now! Note, Kristian's very important words "When all=20
> streaming applications obey this protocol." Usually, as Kristian=20
> alluded to in another message, the transmitter allocates bandwidth.

Actually, I was a bit vague on that point.  It depends on the
application/protocol who is responsible for allocating isochronous
resources.  The only requirement in the IEEE1394 standard is that
somebody has to do it before transmission starts.  For example, there is
an AV/C command, INPUT_SELECT, that asks a sink device to create a
connection, in which case the sink device is responsible for allocating
and later freeing the resources.

> When I was working on dv1394d, I tried to check and set this register
>  because my application is a transmitter (or at least performing IEC=20
> 61883-1 Connection Management Procedures), and we were dealing with=20
> multiple channels of iso comms. DV devices are typically both=20
> receivers and transmitters. However, I noticed some devices=20
> allocating bandwidth when not actively transmitting. We can set the=20
> transmit vs receive mode of the device with some FCP async=20
> transactions, but even though they were set to receive, some still=20
> did not relinquish bandwidth. Therefore, is it the role of libdc1394
> to allocate bandwidth when it tells a camera to transmit?

That's a yes: we're talking about IIDC compliant cameras - I'm not very
familiar with those, but I just browsed through the specification.
Section 3.1 says pretty clearly that it is the responsibility of the
controller, i.e. the PC to allocate isochronous resources, and then
program the channel number and transmission speed into the camera.  Only
then should it ask the camera to start isochronous transmission.

> What if, despite the experience on your camera, a different model
> camera does allocate bandwidth? I do not think there is a reliable
> way to determine this. Therefore, if libdc1394 allocates bandwidth,
> then more bandwidth is allocated than actually in use. Or does IIDC
> spec dictate that camera implementors not allocate bandwidth with
> IRM?

As I said, I haven't worked much with IIDC cameras, but the standard=20
says pretty clearly that the camera is a passive device that should not=20
initiate transactions on its own - including bandwidth alloction.

Kristian