@MickJT
While it's true that you can't limit your upload, it doesn't seem to take over downloading, here.
The official client can't limit uploads either.
You can get your whole download bandwidth by limiting upload; if you don't, you get maybe a quarter, and your internet connection is practically useless until you break ctorrent. It's even worse with routers and cable/DSL connections.
As for not limiting upload, the official bittorrent version can. The --max_upload_rate argument has been present for a long, long while now.
I've ran this for hours, perhaps they forgot the -C cache size argument, and it drained their memory after getting a certain number of pieces.
No, that is not the cause, not on machines with a gigabyte of RAM. In fact we've never been able to find the cause. Could be an original ctorrent bug, could be Miami, could be ixemul, could be gcc... If it works stable for you, good; but remember don't run it on an FFS partition, just in case.
It doesn't use too much cpu (except for the file hash checking when you need to resume something).
I've heard of 70% CPU use with a MOS-native compile sometimes, on a G4! And hashing on a 68k must really, really take ages. And the TCP/IP stack must need a lot of CPU too with all the BT connections. But anyway, that's not really a problem if you don't intend to use your Amiga while it's running, so it's a moot point I suppose.
... and 68k Amigas play music fine, if that's what your gonna be download.
True, maybe you can get whole albums, but BT is for bulk downloads of 700 MB or more. Users shouldn't expect to find mp3s for it.
