As I mentioned earlier in this forum, Ohloh causes severe DOS to my network every week when it processes the GraphicsMagick enlistments. The GraphicsMagick CVS repository is surely one of the older ... [More] and larger ones on the net. Outbound bandwith from my site is limited (somewhere around 80 kilobytes/second). When Ohloh does its weekly processing, it seems to use the least efficient algorithm possible and without enabling data compression. When only a tiny change has been committed since the previous enlistment run (taking only a second or two for CVS update from a remote location), Ohloh will still arrange to peg the link to maximum latency for a full day. It is as if it starts from scratch each week, pulling each and every file revision since the repository was created 12 years ago. That would be gigabytes of data to transfer. This network is used to support the needs of other projects such as libpng and needs to be reasonably available. This abuse is not acceptable to me. If Ohloh does not fix its broken algorithm, I will be forced to remove the enlistments. Today I had to kill off the CVS server process just so I could post to this forum. Bob [Less]

When Ohloh was indexing correctly, it caused no problem for my site. When it went haywire, it maxed it out the transfer rate. Any site which has less outbound bandwith than Ohloh has inbound ... [More] bandwidth would have been brought to its knees. It seems wise for Ohloh to estimate the available bandwidth from the site it is sucking from and throttle back if the remote site is slower. [Less]

GraphicsMagick is still not updating.