<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [ripe-ttraffic #15093] TTM to do list
Henk,
Related to the "install more boxes" and "N^2" items,
I think we need to revisit the design/configuration of
the software running on the boxes (see appended list).
-- Rene
- ControlDaemon:
currently we construct a filter string for BPF packet capturing
that consists all hostnames of all boxes in the configfile.
Question: does that scale? can BPF keep up with the influx
of packets when we have a large (~100 boxes) filter string?
- Send_data:
currently the scheduling sends at most one packet per second
to any box. In 1999 we had to reduce the number of packets send
per host per day to avoid running in 'pulsar' mode.
Question: when more boxes get deployed, do we need sub-second
scheduling, or should we again reduce the number of packets
send per 'connection'?
- Router:
currently each testbox schedules 10 traceroute measurements
to each configured destination in one hour.
Question: when we exand the number of destinations, can we
continue to do traceroutes at that rate? will we need
sub-second scheduling?
- Resource problems
On some occasions (e.g. connectivity problems) machine resource
problems are unavoidable; no more processes / out of swap space.
Question: do we want to leave it to the OS (when possible with a
little help from CFE) to recover from that, or do we want to
(re)design datataking software such that it will never exceed
preconfigured limits of #processes (and thus amount of swap).
<<<
Chronological Index
>>> <<<
Thread Index
>>>