Is it really the same thing? Or is it the foreseen (in the
Changelog) limit of 200 KB/s?
The previous bug
(http://sourceforge.net/tracker/index.php?func=detail&aid=931538&group_id=66404&atid=514393)
is related to an incorrect upload limit (showing X but
capping at Y). This bug I'm not having here anymore (Win98
SE). At what transfer speed you have this problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, my total upstream bandwidth is 35kB/s, it doesn't matter
if I have the cap set at 30 or 200kB/s, a singel transfer will
only go about 1/2 the speed it should, 2 transfer almost get
to full capacity. If I lower the cap to below the speed the
upload is going it slow down of course, but it will never go as
fast as it should be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i also have this problem on winxp.
i put the cap to 300k, a single download go up to 120k, 2
download nearly have the top speed, 3 download go perfectly
@ total of 300k
i have also try to increase the MAX_PUSH but the effect is
not so positive..to view any appreciable change i need to
increase it by a *20 factor, and with this change, a lot of
upload go to "timeout". Changing the timeout in lopster_input
from 50 to 20, 10 (even 1) seem to be ineffective...
bye bye
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's working fine with the 0.9 rc1. After releasing the 0.9
I'll mark this bug as closed if nobody notices this problem
again.
The max limit is now set by MAX_PUSH * 100 => 1000 KB/s
(MAX_PUSH is 10 K).
I'll be less if there's not enought CPU. Does anyone needs
more than this? If yes, let me know so I'll change MAX_PUSH
to a bigger value. If you don't exceed the maximum value
(1000 KB/s), the cap *must* be the one you configured (it's
obviously needed a local test if you want to make sure that
the problem is with the client, and not with the connection).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just finished an upload test with the new version
(0.9rc1) and the speed still won't go to the max. I know
nothing else it eating any of my upstream. And I tested the
same way with the native lopster. Max speed achieved on
winlop: 23kB/s. Max on Lopster: 36kB/s. Also checked with
several other apps, soulseek and xnap. Full speed was
available. And I made sure it wasn't just showing that way
on my end of course. Same speed appeared on the recieving
end as well. Tested on win2k pro sp4 and winxp pro sp2rc2.
Native lopster tested on Debian.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Changed to the 0.9 group. I don't have win2k/xp. Can anyone
who have these crap^H^H^H^Hwindows versions and know how to
code give me a hint (or better yet, a patch) to make the
uploads work in a reliable way (preferably no threads, they
tend to crash everything)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally fixed it. After all the main culprit was Winsock.
After trying a test with a simple client/server I found out
that independently of the size used in send/recv, the
transfer was always capped at 4~5 MB/s. The problem is that
Winsock needs to copy the data from the socket's internal
buffer to the user buffer; and somehow it is damn slow at
doing it!!
Using setsockopt I set the SO_RCVBUF and SO_SNDBUF buffers
to zero, so winsock transfers the data directly to the user
buffer. My client/server test then could easily transfer at
~35 MB/s. After testing this change in winlop I could
transfer a single file (local) at ~3.5 MB/s (my HD is *very*
fragmented, probably this is the bottleneck now :( ).
Anyways, it went much faster than WinMX now.
Good it's just in time for the 0.10 this sunday. ;)
PS: for didactic purposes I'm attaching the client/server
test code, if there's anyone interested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not all fixed yet. The transfers are now around 1.2 MB/s.
I'll try a multi-threading hack in the 0.11 version. For
now, on 0.10, it'll remain as it is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After some extensive testing I'd definitely have to agree
that it is not yet fixed. In 0.11 RC1 single transfers are
considerably slower than when 2 different transfer are
going. It is also quite sporadic. I've test the hell out
of this. I have a 1mb upload line transfer peak at 65kB/s.
I think there is something seriously wrong with the
uploading stuff in for WinLop. Don't think it's the dev's
fault, rather just difficult porting. Can't maintain
reliable upload transfer speeds. Tested using the same
people using other opennap clients and acheived full
transfer speeds.
This is on Windows XP Pro, SP2. Keep up the good work.
This is almost perfect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ignore the last comment. It seem my ISP just started doing
some kind of traffic filtering. Which explains why my
testing was giving consitently bad results. Sorry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=472304
Is it really the same thing? Or is it the foreseen (in the
Changelog) limit of 200 KB/s?
The previous bug
(http://sourceforge.net/tracker/index.php?func=detail&aid=931538&group_id=66404&atid=514393)
is related to an incorrect upload limit (showing X but
capping at Y). This bug I'm not having here anymore (Win98
SE). At what transfer speed you have this problem?
Logged In: YES
user_id=1016507
well, my total upstream bandwidth is 35kB/s, it doesn't matter
if I have the cap set at 30 or 200kB/s, a singel transfer will
only go about 1/2 the speed it should, 2 transfer almost get
to full capacity. If I lower the cap to below the speed the
upload is going it slow down of course, but it will never go as
fast as it should be.
Logged In: NO
i also have this problem on winxp.
i put the cap to 300k, a single download go up to 120k, 2
download nearly have the top speed, 3 download go perfectly
@ total of 300k
i have also try to increase the MAX_PUSH but the effect is
not so positive..to view any appreciable change i need to
increase it by a *20 factor, and with this change, a lot of
upload go to "timeout". Changing the timeout in lopster_input
from 50 to 20, 10 (even 1) seem to be ineffective...
bye bye
Logged In: YES
user_id=472304
It's working fine with the 0.9 rc1. After releasing the 0.9
I'll mark this bug as closed if nobody notices this problem
again.
The max limit is now set by MAX_PUSH * 100 => 1000 KB/s
(MAX_PUSH is 10 K).
I'll be less if there's not enought CPU. Does anyone needs
more than this? If yes, let me know so I'll change MAX_PUSH
to a bigger value. If you don't exceed the maximum value
(1000 KB/s), the cap *must* be the one you configured (it's
obviously needed a local test if you want to make sure that
the problem is with the client, and not with the connection).
Logged In: YES
user_id=1016507
I've just finished an upload test with the new version
(0.9rc1) and the speed still won't go to the max. I know
nothing else it eating any of my upstream. And I tested the
same way with the native lopster. Max speed achieved on
winlop: 23kB/s. Max on Lopster: 36kB/s. Also checked with
several other apps, soulseek and xnap. Full speed was
available. And I made sure it wasn't just showing that way
on my end of course. Same speed appeared on the recieving
end as well. Tested on win2k pro sp4 and winxp pro sp2rc2.
Native lopster tested on Debian.
Logged In: YES
user_id=472304
Changed to the 0.9 group. I don't have win2k/xp. Can anyone
who have these crap^H^H^H^Hwindows versions and know how to
code give me a hint (or better yet, a patch) to make the
uploads work in a reliable way (preferably no threads, they
tend to crash everything)?
Simple server test that sends a lot of random data
Logged In: YES
user_id=472304
Finally fixed it. After all the main culprit was Winsock.
After trying a test with a simple client/server I found out
that independently of the size used in send/recv, the
transfer was always capped at 4~5 MB/s. The problem is that
Winsock needs to copy the data from the socket's internal
buffer to the user buffer; and somehow it is damn slow at
doing it!!
Using setsockopt I set the SO_RCVBUF and SO_SNDBUF buffers
to zero, so winsock transfers the data directly to the user
buffer. My client/server test then could easily transfer at
~35 MB/s. After testing this change in winlop I could
transfer a single file (local) at ~3.5 MB/s (my HD is *very*
fragmented, probably this is the bottleneck now :( ).
Anyways, it went much faster than WinMX now.
Good it's just in time for the 0.10 this sunday. ;)
PS: for didactic purposes I'm attaching the client/server
test code, if there's anyone interested.
Simple client that receives data and shows the aproximate download speed
Logged In: YES
user_id=472304
Not all fixed yet. The transfers are now around 1.2 MB/s.
I'll try a multi-threading hack in the 0.11 version. For
now, on 0.10, it'll remain as it is.
Logged In: YES
user_id=1016507
After some extensive testing I'd definitely have to agree
that it is not yet fixed. In 0.11 RC1 single transfers are
considerably slower than when 2 different transfer are
going. It is also quite sporadic. I've test the hell out
of this. I have a 1mb upload line transfer peak at 65kB/s.
I think there is something seriously wrong with the
uploading stuff in for WinLop. Don't think it's the dev's
fault, rather just difficult porting. Can't maintain
reliable upload transfer speeds. Tested using the same
people using other opennap clients and acheived full
transfer speeds.
This is on Windows XP Pro, SP2. Keep up the good work.
This is almost perfect.
Logged In: YES
user_id=1016507
Ignore the last comment. It seem my ISP just started doing
some kind of traffic filtering. Which explains why my
testing was giving consitently bad results. Sorry.