> 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.
Fair enough. Still, that's the way ctorrent does things. For me it's not a reason not to put it on Aminet.
> 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 didn't know about that.. I haven't been able to list all the arguments by running btdownloadgui.exe without arguments, the list runs off the screen. I'll have to look them up on the net somewhere.
> 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.
I use PFS3. It seems to be stable here, but I haven't "thoroughly" tested it. I don't want to download something huge just to test it out.
> 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.
45-50% cpu on my 68040/40. It's been compiled with no special flags either. So it should work even on a 68000. Hashing does take quite a while
1.5 minutes for a 44meg file with 180 pieces.
[Edit] I forgot ctorrent uses parts of OpenSSL and OpenSSL was compiled for a 68020.
>> ... 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.
Well... I compile things as a hobby.
