<<< 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 >>>