Re: [Gtk-gnutella-devel] [scott@illogics.org: gtk-gnutella 0.92.1

[Jeroen Asselman]

Hi,

Now I am confused. So when you enable bandwith control uploads do start, 
and when you disable it, they don't start?

btw: I know dates are way in the future when bandwith control is 
disabled. I'll change this one day, but has low priority for me at the 
moment.

- Jeroen

Scott Walters wrote:

Hi Jeroen,

1 upload per host instead of 2 doesn't seem to affect anything. With no
bandwidth control options set, and lots of traffic, it still sets
queue dates way into the future. With stringent bandwidth control option
set, the first upload starts immediately and the queue time for the next
uploads are all reasonable.
-scott

On  0, Jeroen Asselman <[EMAIL PROTECTED]> wrote:
 

--=-l2/kC7ioF/MjVPSRf274
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Op wo 27-08-2003, om 22:26 schreef Scott Walters:
   

Hi Jeroen,
=20
The number of days for each subsequent slot after 1. The number of
days for slot 1 stays fairly constant, if I remember correctly.
=20
4 Maximum simultanious uploads, 2 Max uploads from single host.
     

OK, PARQ might not like the setting 2 uploads from 1 single host, can
you try to set that to 1?
   

That file was somewhere between 2 and 4 megs, as are almost all of them.
=20
I've tried locking down the bandwidth usage for gnutella traffic
in the config/bandwidth control tab. Incoming traffic and outgoing traffi=
     

c
   

are each 1K/s, and HTTP up and down are each 4K/s. I haven't cought it
uploading anything yet (who would download from a 56k node?)
but it looks like it completed two files in the night and watching it
today, I haven't cought anything in the upload queue.
=20
This is just gross speculation, but is it possible that it is trying to a=
     

nticipate when
   

it will have enough surplus bandwidth and report that time when other cli=
     

ents try to
   

fetch? If I average using 80% of my 56k link, then within a year, at some=
     

point,
   

on average, there should be enough surplus bandwidth to move the file ;)
     

It reports the time calculated from your configured upload bandwith. If
this isn't set, it doesn't calculate an accurate ETA at all.
   

=20
Thanks for your attention and pardon my innane ranting =3D)
=20
-scott
=20
On  0, Jeroen Asselman <[EMAIL PROTECTED]> wrote:
     

=20
Raphael Manfredi wrote:
=20
       

A PARQ bug?

         

I hope not.
=20
       

The last several versions of gtk-gnutella have had an odd quirk for me
- I'm completely unable to upload anything to anyone. Any time someone
tries to fetch a file, the Uploads tab shows the request with a Status=
         

of
   

"Queued (slot 1, ETA: 164d 3h)" or something else equally as silly. If
multiple people are in the queue, the number of days just goes up and =
         

up.
   

The number of days for slot 1?
=20
       

Perhaps I'm missing something obvious, but I'd expect that the first
person in a queue when there are no current uploads would be offered
the file immediately.
=20
         

What are the number of configured uploads slots? How big is the file=20
that is request at slot 1?
=20
- Jeroen
=20
       

--=20
Jeroen Asselman <[EMAIL PROTECTED]>
--=-l2/kC7ioF/MjVPSRf274
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dit berichtdeel is digitaal ondertekend
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD4DBQA/TZRf0HVUBD/WJF0RAhsvAJd+621cbXRJwY/8OlU8Hb/HWCukAKCCWkO9
PheQXPryyF21+TmIkY/CdQ==
=CaGU
-----END PGP SIGNATURE-----
--=-l2/kC7ioF/MjVPSRf274--

   





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel