/me is one bit smarter now
I knew CVS a bit, but was never fond of it at all, so as nextgens
recommended me, i will just leave the update stuff for him. Leaves less
stuff for me to break as well ;)
~Zero3Cool
Ian Clarke skrev:
> On 11 Apr 2006, at 13:18, Zero3Cool wrote:
>> Mhmhmhmhm, nobody g
Mhmhmhmhm, nobody gave me any? :)
I never used SVN before though, all i know is that it's a CVS-like system.
~Zero3Cool
Matthew Toseland skrev:
> Why do you not have SVN access?
>
> On Tue, Apr 11, 2006 at 09:57:54PM +0200, Zero3Cool wrote:
>
>> Version 1.3 is out:
>> - Fixed updater updating
Version 1.3 is out:
- Fixed updater updating version information even if the update failed.
- Changed commenting to use "::" instead of ": " to make some editors
more happy.
~Zero3Cool
Zero3Cool skrev:
> Version 1.2 is out, located at
> http://www.zerosplayground.dk/stuff/update.cmd as always.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> You can? If you don't answer their requests, then your node will be
> backed off. If your node is always backed off then there's something
> wrong. Arguably this is detectable; if a node is backed off more than a
> certain per
.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/5af74c7c/attachment.pgp>
s says so.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/6d2bf168/attachment.pgp>
nt was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/13c9ffcc/attachment.pgp>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> Well to some degree this is damped out by the fact that your immediate
> peers will reject your requests if they are overloaded.
To some degree yeah, but you can still use all their bandwidth without
contributing anything in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> Well, the advantage of what we have is that it is based on well known,
> well studied algorithms which are known to work in practice. So any
> replacement would have to either be some means of enforcing the existing
> algorith
-
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size:
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/016b2e68/attachment.pgp>
I was re-reading the paper "Secure Deletion of Data from Magnetic and
Solid-State Memory"[1], and this section caught my attention.
> The most practical solution to the problem of DRAM data retention is
> therefore to constantly flip the bits in memory to ensure that a
> memory cell never holds a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> Is this the best option? It is perhaps closest to "propagate the load
> back to the originator"?
One disadvantage is that if the originator isn't well behaved, load
limiting won't work - a selfish originator might refuse to t
e. Our Boss says so.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/0cc80259/attachment.pgp>
Version 1.2 is out, located at
http://www.zerosplayground.dk/stuff/update.cmd as always.
Changelog:
- Fixed Freenet status detection for Win2k
- Added zero-size checks for downloaded version information and .jar binary.
- Added some misc info at the top of the script
~Zero3Cool
: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/580093dd/attachment.pgp>
/me is one bit smarter now
I knew CVS a bit, but was never fond of it at all, so as nextgens
recommended me, i will just leave the update stuff for him. Leaves less
stuff for me to break as well ;)
~Zero3Cool
Ian Clarke skrev:
On 11 Apr 2006, at 13:18, Zero3Cool wrote:
Mhmhmhmhm, nobody ga
On 11 Apr 2006, at 13:18, Zero3Cool wrote:
Mhmhmhmhm, nobody gave me any? :)
I never used SVN before though, all i know is that it's a CVS-like
system.
SVN is the successor to CVS, if you know CVS then SVN will be second
nature to you.
Ian.
___
On 11 Apr 2006, at 13:18, Zero3Cool wrote:
> Mhmhmhmhm, nobody gave me any? :)
>
> I never used SVN before though, all i know is that it's a CVS-like
> system.
SVN is the successor to CVS, if you know CVS then SVN will be second
nature to you.
Ian.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> You can? If you don't answer their requests, then your node will be
> backed off. If your node is always backed off then there's something
> wrong. Arguably this is detectable; if a node is backed off more than a
> certain per
Mhmhmhmhm, nobody gave me any? :)
I never used SVN before though, all i know is that it's a CVS-like system.
~Zero3Cool
Matthew Toseland skrev:
Why do you not have SVN access?
On Tue, Apr 11, 2006 at 09:57:54PM +0200, Zero3Cool wrote:
Version 1.3 is out:
- Fixed updater updating version i
Why do you not have SVN access?
On Tue, Apr 11, 2006 at 09:57:54PM +0200, Zero3Cool wrote:
> Version 1.3 is out:
> - Fixed updater updating version information even if the update failed.
> - Changed commenting to use "::" instead of ": " to make some editors
> more happy.
>
> ~Zero3Cool
>
> Zer
Version 1.3 is out:
- Fixed updater updating version information even if the update failed.
- Changed commenting to use "::" instead of ": " to make some editors
more happy.
~Zero3Cool
Zero3Cool skrev:
Version 1.2 is out, located at
http://www.zerosplayground.dk/stuff/update.cmd as always.
On Tue, Apr 11, 2006 at 08:37:06PM +0100, Michael Rogers wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Matthew Toseland wrote:
> > Well to some degree this is damped out by the fact that your immediate
> > peers will reject your requests if they are overloaded.
>
> To some degree y
On Tue, Apr 11, 2006 at 08:35:23PM +0100, Michael Rogers wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Matthew Toseland wrote:
> > Well, the advantage of what we have is that it is based on well known,
> > well studied algorithms which are known to work in practice. So any
> > repla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> Well to some degree this is damped out by the fact that your immediate
> peers will reject your requests if they are overloaded.
To some degree yeah, but you can still use all their bandwidth without
contributing anything in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> Well, the advantage of what we have is that it is based on well known,
> well studied algorithms which are known to work in practice. So any
> replacement would have to either be some means of enforcing the existing
> algorith
Well, the advantage of what we have is that it is based on well known,
well studied algorithms which are known to work in practice. So any
replacement would have to either be some means of enforcing the existing
algorithms (which would require being able to identify local requests,
which is bad...
On Tue, Apr 11, 2006 at 08:12:20PM +0100, Michael Rogers wrote:
> This is a robustness issue as well as a performance issue, because
> without load limiting a small number of senders might be able to flood
> the network.
Well to some degree this is damped out by the fact that your immediate
peers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
> Is this the best option? It is perhaps closest to "propagate the load
> back to the originator"?
One disadvantage is that if the originator isn't well behaved, load
limiting won't work - a selfish originator might refuse to t
Okay, first things first. I have put a change in which I believe will
significantly increase insert performance. It goes as follows:
- Inserts visit many more nodes than requests.
- Therefore they take longer - the round-trip-time part of the throttle
is higher.
- They also have a much higher cha
bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/4dec65fa/attachment.pgp>
> That's a separate mechanism (backoff).
Sorry, I thought backoff was triggered by overload. Are there two
separate load-balancing mechanisms at work?
Thanks,
Michael
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11 Apr 2006, at 09:15, Matthew Toseland wrote:
Which requests should count for load limiting?
Load limiting is the process whereby if we get a RejectedOverload or a
timeout we reduce the rate at which we send (locally originated)
requests, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11 Apr 2006, at 09:15, Matthew Toseland wrote:
> Which requests should count for load limiting?
>
> Load limiting is the process whereby if we get a RejectedOverload or a
> timeout we reduce the rate at which we send (locally originated)
> request
Boss says so.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/47fc9d46/attachment.pgp>
s scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/bdbc62b7/attachment.pgp>
Ian Clarke wrote:
> I believe another way to suppress the influence of outliers is to use
> a geometric mean, ie. rather than adding N numbers and dividing my
> N, you multiply the N numbers, and take the Nth root of the result.
>
> Ian.
Ah, yes,this seems to be true. It is also always less than
> - If it is below 1000ms, we accept all requests.
> - If it is above 2000ms, we reject (almost) all requests.
> - If it is between we accept some requests but not all.
If half your peers are overloaded but the other half are OK, would you
reject all requests with equal probability or selectively
Version 1.2 is out, located at
http://www.zerosplayground.dk/stuff/update.cmd as always.
Changelog:
- Fixed Freenet status detection for Win2k
- Added zero-size checks for downloaded version information and .jar binary.
- Added some misc info at the top of the script
~Zero3Cool
Which requests should count for load limiting?
Load limiting is the process whereby if we get a RejectedOverload or a
timeout we reduce the rate at which we send (locally originated)
requests, and if we don't, we increase it.
The original intention I think, based loosely on the TCP-over-Ethernet
On Tue, Apr 11, 2006 at 11:49:00AM +0100, Michael Rogers wrote:
> >That's a separate mechanism (backoff).
>
> Sorry, I thought backoff was triggered by overload. Are there two
> separate load-balancing mechanisms at work?
Not exactly, the above decides whether to send a RejectedOverload (in
orde
That's a separate mechanism (backoff).
Sorry, I thought backoff was triggered by overload. Are there two
separate load-balancing mechanisms at work?
Thanks,
Michael
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/
Why are inserts so slow?
Well, inserts visit more nodes. This means:
a) They take longer, (quite a lot longer) and
b) They are more likely to get a RejectedOverload (or a timeout).
Since our calculation of when we can send inserts is based solely on
these two factors... this results in us sending
d text was scrubbed...
Name: median.patch
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060411/f6d3f0a8/attachment.ksh>
That's a separate mechanism (backoff).
On Tue, Apr 11, 2006 at 10:46:38AM +0100, Michael Rogers wrote:
> >- If it is below 1000ms, we accept all requests.
> >- If it is above 2000ms, we reject (almost) all requests.
> >- If it is between we accept some requests but not all.
>
> If half your peers
- If it is below 1000ms, we accept all requests.
- If it is above 2000ms, we reject (almost) all requests.
- If it is between we accept some requests but not all.
If half your peers are overloaded but the other half are OK, would you
reject all requests with equal probability or selectively rej
Ian Clarke wrote:
I believe another way to suppress the influence of outliers is to use
a geometric mean, ie. rather than adding N numbers and dividing my
N, you multiply the N numbers, and take the Nth root of the result.
Ian.
Ah, yes,this seems to be true. It is also always less than the
ar
:P - But as i pointed out i only run XP, so my chances of doing proper
Win9x/Win2k (boooh :P) testing is kind of limited, but give me feedback
and i will do what i can. I got a mail from search4answers earlier today
about Win2k missing the "sc" (tool for managing services, included with
WinXP,
Matthew Toseland skrev:
> On Sat, Apr 08, 2006 at 02:51:51AM +0200, Zero3Cool wrote:
>
>> - As this script will update itself as well,
>> https://emu.freenetproject.org/svn/trunk/apps/installer/installclasspath/windows/update.cmd
>>
>> *must* be updated as well (assuming you are satisfied with
50 matches
Mail list logo
