Bandwidth limitations

[drgrussell]

For some wierd reason users have started using the site as a way to surf the web... I guess this is in the belief that such things are anonomous, or that they are unable to surf in another way. I should again warn you that this is not anonymous, and unlike ISPs I reserve the right to keep all data forever. This is permitted under the DPA as this is an ongoing research activity. All traffic is logged, both incomming and outgoing.

Anyway, I have started to implement bandwidth limiting features on the site. For now I have placed limits on squid's proxying rate, reducing this significantly from the maximum possible. This should only have an impact on cache misses for external webservers. I have chosen rather small and sad rates for now, and will monitor the system performance and user feedback. If you find you are now unable to do something which you could do before, and that "something" is not unreasonable, I will review this decision.

For most users this change should be invisible.

[drgrussell]

Continuing on from the squid bandwidth limitations, I am now testing traffic shaping code using tc. This should increase the reliability of the system by giving the daemon communication channels more priority for the available bandwidth. This will continue to be tested over the next week.

[drgrussell]

Traffic shaping is now in place. Currently the settings are approximately
16K/s for web downloads, while virtual network transfers are 128k/s minimum and 1024 maximum transfer limits.

I will continue to monitor the network to see if these limits are too harsh or to generous (probably too harsh).

G.