----- Original Message -----
From: "Blue Boar"
Sent: Saturday, November 29, 2003 9:17 AM
Subject: Re: [Ethereal-dev] Redesign of the WHOLE Ethereal main menu
> Ah, so maybe there's a non-cosmetic reason for it to be a seperate window,
> then? There's something in the gtk that allows a seperate window to be
> responsive, and not a section of the main window? I'm asking, I know
> nothing about this gtk.
Yes.
However, I think we should get rid of the percentage bars or whatever you
call them and just
show the percentage number. Showing both is redundant.
Maybe it would be sufficient to do something like making the small capture
window "always on top"?
I am sure GTK would have some sort of setting to specify that a specific
window is always going to be
either ontop of everything else, or ontop of another specific window.
>
> >
> > This is for performance since having the gui completely responsive at
this
> > point will make ethereal slower.
> > When etehreal slows down, the bandwidth treshold where we can capture
> > without packetloss is decreased.
> <snip>
> > Many people use Ethereal for high throughput high speed links.
> > For capturing medium to fully saturated GbE links ethereal is useless
and
> > tethereal must be used.
> > For capturing medum utilized 100baseT links Ethereal CAN be used if
"update
> > in realtime" is not enabled.
> > For capturing low utilized 100baseT links or 10baseT links ethereal with
> > "update in realtime" can be used.
>
> Is it safe to assume that if you had auto-scroll on when you started, then
> the ability to turn it off on the fly would improve performance in that
> circumstance?
>
> I certainly don't want to push for any chages that will have a large
impact
> on performance or usability. I was just hoping for some small UI
> improvements (improvements for my use of Ethereal, of course.)
Thing is that IF we are to display the packet summary line, then we need to
dissect the entire packet.
This is slow and impossible to do in real time unless the link is virtually
idle.
Other things like using display filters/color filters also makes it require
a full dissection of each packet.
On the other hand,
the proper way to do high performance capturing is using tethereal some
linux patches and a dedicated box with
a very fast and low cpu disk subsystem.
IMHO a box that cant capture a full Gbe link to disk is broken. (talking
about streaming to disk, not something stupid as
capturing to RAM, anyone can do that.)
Seriously. The current state of capture devices is rediculous.
Would any of you be willing to pay say 100.000USD with full support for a
year for a box that
could stream a reasonably saturated GbE link to disk at wire speed?
I.e. streaming a few minutes worth of data to disk at full GbE speed.
The box would be luggable.
I find it offensive that people build these low performance boxes using w2k
that max out over a few hundred MBytes/second.
That is slomo speeds.
>
> I'll work on some mockups. If there's general agreement that some of my
> requests are low impact, then I can focus on those. So far, I don't hear
> any general problem with a Capture->Stop menu item, barring any immediate
> changes to go with it?
sounds good to me.
