David,
roughly speaking, the "price" of one frame, in a transmission time
terms, can be computed by the following formula:
N * (size + C),
where C is a constant that depends on a media type and media conditions.
For Ethernet the C is about 100-200, taking in account inter frame gap
(0.6 microseconds at 100 mbps, 6 microseconds at 10 mbps), the bakeoff
time, the minimal Ethernet frame size (64 bytes) and headers. This
constant will tend to grow with the growing network load.
For 802.11 the C is much higher. Say 400-500 for unicast and 200-300 for
multicasts. Multicasts are noticeably cheaper, because there is no ACK
following the multicast transmission. These numbers are not 100% precise
(sorry, I'm a bit lazy to carefully re-read standard now), but gives
more-or-less reasonable approximation.
For ADSL I believe the constant C is noticeably smaller that for Ethernet.
Please note also that if 2 computers are connected via long distance
Internet, short frames sometimes tend to come before long frames. I
believe it happens because if traffic is shaped somewhere in a path, the
traffic shaper may work in terms of payload bytes rather in a terms of
frame count. So if limit is almost reached for the given timeslice, this
is possible that short frame will be transmitted, why long frame will be
delayed.
The probability of such a reordering is noticeable enough - say, 1-2% of
frames may be reordered.
David Barrett wrote:
> So I’m having a discussion with a friend, and we’re debating what seems
> like an obvious point:
>
> Is it actually any cheaper to send a 0-byte UDP packet than to send one
> that is sized at the MTU?
>
> I’d **hope** that it’s cheaper, but I don’t honestly know if this is the
> case.
>
> Now of course the overhead of UDP, IP, Ethernet and so on is fixed
> irrespective of the UDP payload size. But I don’t know enough about the
> lower layers of the protocol stack to say with certainty that more
> 0-byte UDP packets can be delivered per second over (say) a typical DSL
> connection than a 1300 byte UDP packet. Do you know?
>
> For example, I’m kinda sketchy about the physical layer of Ethernet.
> But if two computers are on the same Ethernet, then they need to
> broadcast on the same physical wire. I don’t know precisely what that
> entails, but I assume that takes a nonzero amount of time, especially if
> there is a collision to resolve. Is it possible that the simple
> overhead of sending **any** packet dwarfs the amount of time it takes to
> send the payload?
>
> In other words, to what degree should a UDP protocol attempt to shave
> off that extra few bytes per packet?
>
>
>
> -david
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> p2p-hackers mailing list
> [email protected]
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
