Andrew McGregor

  • Email:
  • Expertise: Wireless
  • Registered on: 08/01/2011
  • Last connection: 08/01/2011

Projects

  • Bloat (Developer, 08/01/2011)
  • Cerowrt (Developer, 08/01/2011)
  • codel (Developer, 05/06/2012)

Activity

Reported issues: 0

09/11/2011

02:54 pm Cerowrt Bug #262: poor wireless performance in smoketest rc6
My test had neither Babel nor multiple interfaces (but did bridge both radios and the lan together). So, it's not Ba...

09/10/2011

11:52 pm Cerowrt Bug #262: poor wireless performance in smoketest rc6
Important to benchmarking this stuff, although it is not in play in the present test, since Nagle has nothing to do w...
05:26 pm Cerowrt Bug #262: poor wireless performance in smoketest rc6
It's something to do with ICMP rate limiting in OS X. I can reproduce it with my own openwrt build:
root@OpenWrt:~#...

09/06/2011

03:50 am Cerowrt Bug #262: poor wireless performance in smoketest rc6
Ok, if it's that consistent, I'll call the test valid.
Dave, a few millimeters can be significant... but if you get ...
02:25 am Cerowrt Bug #262: poor wireless performance in smoketest rc6
So, I have one issue with the test methodology... equidistant doesn't cut it, you need to test the same pair of devic...

08/05/2011

11:39 am Cerowrt Bug #216: Infiinite retry for ping
Ok, this patch applies on top of Felix' last set of changes, and produces really spectacular results: about 2x better...

08/03/2011

03:44 pm Cerowrt Bug #216: Infiinite retry for ping
Here's what I've been working on. Note that this includes a version of Felix' patch that changes the interpretation ...
02:08 pm Cerowrt Bug #216: Infiinite retry for ping
Just starting to roll them up.
I got g to suck much less.
Note that although I have not reduced ATH_TXBUF in these,...
09:16 am Cerowrt Bug #216: Infiinite retry for ping
Tickless was invented by SGI, and the MIPS CPU architecture was designed to run tickless, so it's nearly optimal for ...
08:16 am Cerowrt Bug #216: Infiinite retry for ping
David Taht wrote:
> In looking over your tests I suspect the reason your latency under load
> remains good is that ...

Also available in: Atom