Chris Wilson wrote:
Hi Ulf,
Imagine you have a DSL link which is 1024 kbit down, 128 up. Your link
is performing slowly, and you want to know why. One user is downloading,
but has carefully throttled their own bandwidth (or you did it for them)
to 800 kbits, so they are not overloading the link. Someone else is
uploading 128 kbits and flooding your upstream. This is the real
culprit, but it would be easy to miss this 128 kbit stream in the
"noise" of the 800, if they were not separated by direction.
I can imagine having a DSL link which is sometimes performing slowly but
I usually know exactly the case as I've done the mess myself ;-)
So what you need here is not a simultaneous view of both incoming and
outgoing at the same time, but a simple filter mechanism like "show me
only incoming / outgoing traffic" or alike.
I'm not expecting users to work with saved capture files in this kind of
scenario, but if they did, they could easily override the default
local/remote filter. The defaults should "just work" for the common
case, real time live sniffing and graphing.
Be careful with the "common case" term in the Ethereal community, I got
some very strange mails what the common case is :-) The points of view
*really* widely divide here ...
It should not be necessary to override the local/remote filter, as this
will be switched off seeing both directions as default (which makes most
sense at first sight), but an easy way to enable an according filter.
Not sure that the maximum theoretical bandwidth matters. If you are
filling up the link, the graph will "flat top". This is the danger sign
that you want to look out for. Where it flat tops (how high it goes) is
largely irrelevant unless you think your broadband provider is cheating
on you.
If you don't know the possible maximum, the current value is usually
pretty meaningless.
However, if you know the maximum desired speed this might makes sense.
And for example: when using a DSL line it's probably not the line speed
interesting where you're capturing at (e.g. 100MBit/s Ethernet) as the
real interesting limit is the DSL line (e.g. only 1MBit/s) but you may
know the expected line speed.
That boils down to improving the IO graph feature we currently have,
plus bringing it to a more exposed place (e.g. a tab in the main window).
I didn't think it was possible to save sensible defaults for this
option, but I've just discovered that it is, thanks!
Unfortunately, that's true for a lot of things you've mentioned. Having
an implementation that's working somehow is one thing.
Having a GUI implementation that's easy and intuitive to use is a real
tedious task which might take much longer than the "few weeks" you've
mentioned earlier. Don't underestimate this!
Regards, ULFL