-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Howdy, all
So. I've been working through Appendix A of RFC 2889, and no offense to
anyone, but it's a mess.
* The formulas are incomplete. The TXTIME formulas has no numerator.
(I'm guessing this is a known bug)
* The included example doesn't agree with the IBG formula
According to the RFC,
[(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG
IBG = -----------------------------------------------------------
SPEED
Now, try the example:
Example:
LENGTH = 64 bytes per frame
LOAD = 100 % offered load
BURST = 24 frames per burst
SPEED = 10 Mbits/sec (Ethernet)
DURATION = 10 seconds test
you get IBG = IFG
I guess this makes sense for 100% load. But given the answers in the
example, I think the load is supposed to be 50%. However, even with 50%
load, the RFC formula gives IBG = 1622.4 microseconds which is off by 1
IFG from the example:
1622.4 micro - 9.6 micro = 1612.8 micro
This suggests that the example is using
[(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)]
IBG = -----------------------------------------------------------
SPEED
Anyway this leads me to the question: What is the IBG supposed to be?
Does the IBG contain the IFG + extra? Or is the IBG seperate from the IFG?
Put another way: At 100% load is my IBG supposed to equal the IFG? (RFC
formula)
or does it equal 0? (RFC example)
Personally, I'm thinking that the IBG is really IFG + extra and that the
formulas in the RFC should be:
[(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG
IBG = -----------------------------------------------------------
SPEED
BURST * (IFG + 64 + 8*LENGTH) - IFG
TXTIME = ------------------------------------------
SPEED
This means that for 50% load, the example values would have the
following answers:
IBG = 1622.4 micro (instead of 1612.8 micro)
TXTIME = 1603.2 micro
#OFBURSTS = 3101 (instead of 3110)
Or did I miss something?
* (NIT) The range for LOAD in the IBG equation should be written as (0,
100] since 0 makes the equation nonsensical, i.e. you can't divide by 0
(again, this is obvious, or at least should be)
* (NIT) Giving results in seconds seems silly when the Ethernet transmit
clock is +/- 100 ppm. Bit times would at least be accurate.
Timmons
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
iD8DBQFHMhdXPps6tU0vhXERAlQuAJ48LW0oS8KLY4XFxln61eA2hsfdEQCdHkeE
HNA8nXCkMF5RmeZAbdFT6FQ=
=AgJH
-----END PGP SIGNATURE-----
_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg