Mesh Testing: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 32: | Line 32: | ||
* Suspend/resume: Off vs. on, wake-on-unicast vs. wake-on-multicast |
* Suspend/resume: Off vs. on, wake-on-unicast vs. wake-on-multicast |
||
* Block multicast in route table (are there other sources of multicast packets other than the above?) |
* Block multicast in route table (are there other sources of multicast packets other than the above?) |
||
* Would turning down the tx power (globally, since we can't do it per-packet) help with the dense mesh problems? |
|||
* Are there other mesh parameters to tweak? Path request timeout, for example. |
* Are there other mesh parameters to tweak? Path request timeout, for example. |
Revision as of 05:03, 22 February 2008
This page describes the network testing that will be performed on Monday Feb 25th at 1cc.
Setup:
- Start with ten machines, keep adding ten at a time while it is useful to do so.
Measurements to make during each test (in addition to workload-specific measurements):
- Spectrum utilization -- as measured w/ spectrum analyzer and/or from wireshark
- Wireshark may be able to break down bandwidth by packet type
- Remaining bandwidth -- attempt to download a large file on one machine during test, record time taken or bandwidth achieved.
- Total # of laptops seen on mesh view on all numbers (should be n^2).
Workloads -- tests to perform, along with their quantitative metrics:
- Idle load.
- Every machine coming out of suspend (or booting).
- Every machine trying to register with school server -- Number of machines that failed the first attempt, failed second attempt, etc.
- Ricardo's web spider at various rates of download (download 1k page/second, etc)
- Read -- if one laptop shares a PDF, how many laptops fail to retrieve it?
- Distance -- binary success/fail. Are there other metrics?
- Write -- automate pressing N characters a second for small N, look at received rate/update time, increase number of participants per document.
- olpc-update -- number of machines upgraded in 1 hour
Variables to investigate:
- Set mesh ttl to 1 for every packet
- Change bcast/mcast rate on every node
- Jim's Avahi config 30% fixes?
- Presence: Benchmark bandwidth use of Avahi vs. Cerebro vs. no presence?
- Collaboration: Benchmark switching from multicast to unicast?
- Suspend/resume: Off vs. on, wake-on-unicast vs. wake-on-multicast
- Block multicast in route table (are there other sources of multicast packets other than the above?)
- Would turning down the tx power (globally, since we can't do it per-packet) help with the dense mesh problems?
- Are there other mesh parameters to tweak? Path request timeout, for example.