| Bug ID |
8703
|
| Summary |
TCP conversation: bits/sec calculation misleading
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.8.7
|
| Hardware |
x86-64
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Wireshark
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Version 1.8.7 (SVN Rev 49382 from /trunk-1.8)
--
TCP conversation list has 527 entries. 1 of them stands out as a relative
screamer: 2.6 Mb/s !
on closer inspection, though, this is just a Wireshark-triggered red herring.
Here are the details:
2 packets were sent
-- pkt 1 had 54B
-- pkt 2 had 60B
-- delta t between packets = 351 usec.
WS is calculating transport of 8 b/B * 114 B / 351 usec = 2,598,290.598291
b/sec
My estimation: Not Really!
I can't immediately offer suggestions for more realistic calculations, but this
situation is a kind of corner case that perhaps should be thought about for
special handling.
There's a similar conversation elsewhere in this capture:
- 4 packets
- 54 + 60 + 54 + 50 B = 228 B
- delta t
--- pkt1 to pkt4: 20.754765 sec
--- pkt1 to pkt2: 432 usec
--- pkt3 to pkt4: 360 usec
- 87.9 b/s
I'd be remiss not to mention that the "conversations" that lead to these #s are
a bit screwy themselves, as all 6 messages are TCP with sequence # = 1 and FIN
+ ACK set, and *no* communication from the destination peer. (This is traffic
within a corporate network, and not some experimental or academic environment.)
You are receiving this mail because:
- You are watching all bug changes.