Re: [freenet-support] Freenet 0.7.5 build 1327 (small, preparatory)

2011-01-16 Thread Dennis Nezic
On Sun, 16 Jan 2011 10:06:04 +0300, Volodya wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/16/2011 08:33 AM, Dennis Nezic wrote:
  On Sun, 16 Jan 2011 08:00:08 +0300, Volodya wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  (Off topic hand waving, how hard is it, honestly, to have a
  counter on each incoming packet, and to only accept
  inputBandwidthLimit per second? (And perhaps to add clever
  debugging messages, for now, if the node is ever seen
  significantly exceeding this limit?))
 
  How do you count the bandwidth?
 
  Packets are discrete while bandwidth is continuous.
 
  Let's say that you have a bandwidth limit of 5 KiB per second; now
  imagine that a packet comes in that is 42 kilobits, if you download
  that packet in less than a second, you have gone over your limit.
  But you cannot slow down half way through a packet.
 
  You have said that you do not think that Freenet should average
  things out, but that is the only way to move from discrete to
  continuous math while preserving any sense of sanity.
  
  True. Are Freenet's packets that big? (Smaller packet sizes would be
  one solution for better bandwidth management.) I guess the discrete
  spikes aren't really a problem though, but rather those massive and
  continuous flows that swamp my connection -- as if the packet
  counter suddenly decided to stop working altogether, or something.
 
 I have just given an example, it had little to do with Freenet packet
 size.
 
 Still what i was pointing towards is that you need to average things
 out over some period of time. Perhaps the problem is in something
 different, but it could be that it selects some time period that is
 too large or too small.

(In the meantime, till the bug (and possibly the feature) settle
down, I have put in place an iptables rule+tc bandwidth limiting
filter.)
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7.5 build 1327 (small, preparatory)

2011-01-15 Thread Dennis Nezic
On Thu, 13 Jan 2011 10:21:37 -0500, Dennis Nezic wrote:
 On Wed, 12 Jan 2011 20:31:31 +, Matthew Toseland wrote:
  Build 1327 includes three bugfixes which will help to debug 1328,
  which hopefully will finally include the new load management
  prerequisites (sending the load messages, two-level timeouts). It
  will be mandatory on Monday but please upgrade now. The three fixes
  are related to:
  - Even if a request takes too long and times out, we need to tell
  the previous node about the timeout. This is necessary for two-stage
  timeout in the next build, which will look out for it to tell
  whether the timeout is the fault of the node we are waiting for or
  is a downstream error we can't do anything about.
  - Ignore some errors caused by nodes still running the old packet
  format (we work around these and they are not interesting; the same
  error is however interesting if it happens with new packet format).
  - Regard a message as sent after everything in the message has been
  sent once, even if it's not all in flight now due to packets being
  lost causing resends (sent is distinct from acknowledged).
  
  THANKS! Please report any problems you find!
 
 1327 seems a lot more obedient, and hasn't gone berserk after about a
 day of uptime. (Muchos Gracias.)

1327 also goes berserk sometimes, although perhaps less often. Oddly
enough, it goes way way over my limit (for at least a few minutes) when
my connection is congested from other activity. (Aka. the worst
possible time to go berserk.)

(Off topic hand waving, how hard is it, honestly, to have a counter on
each incoming packet, and to only accept inputBandwidthLimit per
second? (And perhaps to add clever debugging messages, for now, if the
node is ever seen significantly exceeding this limit?))
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7.5 build 1327 (small, preparatory)

2011-01-15 Thread Volodya
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 (Off topic hand waving, how hard is it, honestly, to have a counter on
 each incoming packet, and to only accept inputBandwidthLimit per
 second? (And perhaps to add clever debugging messages, for now, if the
 node is ever seen significantly exceeding this limit?))

How do you count the bandwidth?

Packets are discrete while bandwidth is continuous.

Let's say that you have a bandwidth limit of 5 KiB per second; now imagine that
a packet comes in that is 42 kilobits, if you download that packet in less than
a second, you have gone over your limit. But you cannot slow down half way
through a packet.

You have said that you do not think that Freenet should average things out, but
that is the only way to move from discrete to continuous math while preserving
any sense of sanity.

   - Volodya



- -- 
http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast

 None of us are free until all of us are free.~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNMntRAAoJENW9VI+wmYasYEMH/1PK+Ea33qJZRGDEvFbktznX
MRzyXFT/GYH3KTPQvD/aHcKcN81Rtc3aVCY1sHJzkdb2SmeSoV1Kilyd/Iw2kcl5
lk4HNd+to7XBQcsggBBPYMMV5I/GGQDdI1DYAbOmkcU+B7oTElCEktsI4PcyGNbk
7lBViMjqFYnhZhQDM3dqsJv6ik5WqHIS5DY3OD8b/C3ngERm3Au9pFBw8HGWwve9
stSrFhideHkjpSaaeoJMEt1L0cEDH42Mr6LO4eO1UdLnM8aG3khUXxvrPxylN8Kb
WjI27kJc3DMnCefgL2xrtahjUVgTjBIJUgmTLIDLY3dFcnhlQl0C4jHfQf2QGjk=
=eYnE
-END PGP SIGNATURE-
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7.5 build 1327 (small, preparatory)

2011-01-15 Thread Dennis Nezic
On Sun, 16 Jan 2011 08:00:08 +0300, Volodya wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
  (Off topic hand waving, how hard is it, honestly, to have a counter
  on each incoming packet, and to only accept inputBandwidthLimit per
  second? (And perhaps to add clever debugging messages, for now, if
  the node is ever seen significantly exceeding this limit?))
 
 How do you count the bandwidth?
 
 Packets are discrete while bandwidth is continuous.
 
 Let's say that you have a bandwidth limit of 5 KiB per second; now
 imagine that a packet comes in that is 42 kilobits, if you download
 that packet in less than a second, you have gone over your limit. But
 you cannot slow down half way through a packet.
 
 You have said that you do not think that Freenet should average
 things out, but that is the only way to move from discrete to
 continuous math while preserving any sense of sanity.

True. Are Freenet's packets that big? (Smaller packet sizes would be
one solution for better bandwidth management.) I guess the discrete
spikes aren't really a problem though, but rather those massive and
continuous flows that swamp my connection -- as if the packet counter
suddenly decided to stop working altogether, or something.
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7.5 build 1327 (small, preparatory)

2011-01-15 Thread Volodya
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2011 08:33 AM, Dennis Nezic wrote:
 On Sun, 16 Jan 2011 08:00:08 +0300, Volodya wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 (Off topic hand waving, how hard is it, honestly, to have a counter
 on each incoming packet, and to only accept inputBandwidthLimit per
 second? (And perhaps to add clever debugging messages, for now, if
 the node is ever seen significantly exceeding this limit?))

 How do you count the bandwidth?

 Packets are discrete while bandwidth is continuous.

 Let's say that you have a bandwidth limit of 5 KiB per second; now
 imagine that a packet comes in that is 42 kilobits, if you download
 that packet in less than a second, you have gone over your limit. But
 you cannot slow down half way through a packet.

 You have said that you do not think that Freenet should average
 things out, but that is the only way to move from discrete to
 continuous math while preserving any sense of sanity.
 
 True. Are Freenet's packets that big? (Smaller packet sizes would be
 one solution for better bandwidth management.) I guess the discrete
 spikes aren't really a problem though, but rather those massive and
 continuous flows that swamp my connection -- as if the packet counter
 suddenly decided to stop working altogether, or something.

I have just given an example, it had little to do with Freenet packet size.

Still what i was pointing towards is that you need to average things out over
some period of time. Perhaps the problem is in something different, but it could
be that it selects some time period that is too large or too small.

- Volodya


- -- 
http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast

 None of us are free until all of us are free.~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNMpjAAAoJENW9VI+wmYasuf4H/0qUPAfEEYIKAWfdaweVlZCv
dqTShmmNur1eQ+96ZWxTI0qbQ1+vYe774l25m0dAK9uds4nK+v0G+duDRhUdrkMY
wSwOsfDXMqkyg7WgI4D9IIzer0nJoUJAfYhjrpwRA7fhX3OQJQizyMdEhL34bc4f
3kUe6ItH1A3ZYdpxdrp3TsRiT2hiciWimmqV2+D+P1aMK5ZBVxAPdY7qUgA1UpOh
MSAhmfSLfQQOJrbdwejfO5eftNhYgMyrAuYPXCAkb3GNL1IPTE54eQ0BcMlPOpmj
jfp1IgrHHDmNP7fVDOn7goxf5Vn/v3rIVdHXTTgbyUlh46EFC7h4/J6Ka+gKa3E=
=WaFe
-END PGP SIGNATURE-
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7.5 build 1327 (small, preparatory)

2011-01-13 Thread Dennis Nezic
On Wed, 12 Jan 2011 20:31:31 +, Matthew Toseland wrote:
 Build 1327 includes three bugfixes which will help to debug 1328,
 which hopefully will finally include the new load management
 prerequisites (sending the load messages, two-level timeouts). It
 will be mandatory on Monday but please upgrade now. The three fixes
 are related to:
 - Even if a request takes too long and times out, we need to tell the
 previous node about the timeout. This is necessary for two-stage
 timeout in the next build, which will look out for it to tell whether
 the timeout is the fault of the node we are waiting for or is a
 downstream error we can't do anything about.
 - Ignore some errors caused by nodes still running the old packet
 format (we work around these and they are not interesting; the same
 error is however interesting if it happens with new packet format).
 - Regard a message as sent after everything in the message has been
 sent once, even if it's not all in flight now due to packets being
 lost causing resends (sent is distinct from acknowledged).
 
 THANKS! Please report any problems you find!

1327 seems a lot more obedient, and hasn't gone berserk after about a
day of uptime. (Muchos Gracias.)
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


[freenet-support] Freenet 0.7.5 build 1327 (small, preparatory)

2011-01-12 Thread Matthew Toseland
Build 1327 includes three bugfixes which will help to debug 1328, which 
hopefully will finally include the new load management prerequisites (sending 
the load messages, two-level timeouts). It will be mandatory on Monday but 
please upgrade now. The three fixes are related to:
- Even if a request takes too long and times out, we need to tell the previous 
node about the timeout. This is necessary for two-stage timeout in the next 
build, which will look out for it to tell whether the timeout is the fault of 
the node we are waiting for or is a downstream error we can't do anything about.
- Ignore some errors caused by nodes still running the old packet format (we 
work around these and they are not interesting; the same error is however 
interesting if it happens with new packet format).
- Regard a message as sent after everything in the message has been sent once, 
even if it's not all in flight now due to packets being lost causing resends 
(sent is distinct from acknowledged).

THANKS! Please report any problems you find!


signature.asc
Description: This is a digitally signed message part.
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe