Evan Huus
changed
bug 8460
| What |
Removed |
Added |
| Status |
INCOMPLETE
|
CONFIRMED
|
| Summary |
IO Graph does not scale well with large captures
|
IO Graph should not be limited to 100k points (NUM_IO_ITEMS)
|
| Severity |
Normal
|
Enhancement
|
Comment # 7
on bug 8460
from Evan Huus
(In reply to comment #6)
> (In reply to comment #5)
>
> cristian: hi. it works better now indeed. see some comments inline.
Good to hear.
> > (In reply to comment #4)
> > > The limit of 100,000 entries is arbitrary but enforced because graphing at
> > > that level is impossibly slow (the crash was because we weren't respecting
> > > that limit in one place and running past the end of the array).
> >
> > This is still true.
>
> cristian: what does it mean 100k packets nowadays when you have gigabits per
> second in the core networks? anyway the real problem imo is that is not
> really possible to select easily which are the 100k packets that should be
> shown.
It's certainly a less useful limit then when it was created. A few points worth
noting:
- The 100k element array is statically sized. I didn't write the original code
but I suspect it could be dynamically allocated at the right size, including
sizes >100k. Even 100k no longer seems particularly slow on my machine at
least.
- It will hopefully be rewritten in the near future for the Qt port anyways, at
which point this and several other limitations of the original will be able to
be designed away.
- The 100k limit is easily changeable if you build from source - just edit
NUM_IO_ITEMS at line 139 of ui/gtk/io_stat.c. Increasing that value will result
in greater memory usage but should also allow you graph more points. It may be
worth increasing this value by default as a temporary work-around until the Qt
rewrite is ready - if so, could you suggest a reasonable compromise value?
Thanks,
Evan
You are receiving this mail because:
- You are watching all bug changes.