aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: 1 [2]

Author Topic: Resharing after file removal.  (Read 8053 times)

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Resharing after file removal.
« Reply #15 on: November 03, 2008, 04:46:23 PM »

Are you seriously suggesting a Poisson distribution claiming that the event of a file not being in the disk anymore and the event of someone reaching the top of the queue FOR THAT FILE, WHICH IS NOT THERE, are not correlated?

Have you done your homework before posting?
Logged

Coronas

  • Approved Newbie
  • *
  • Karma: 1
  • Offline Offline
  • Posts: 48
Re: Resharing after file removal.
« Reply #16 on: November 03, 2008, 09:09:50 PM »

 
[Do you any idea what "Schrödingers cat" is?
No, I'm just practicing random ranting. :-*
Logged

lfroen

  • Guest
Re: Resharing after file removal.
« Reply #17 on: November 04, 2008, 09:55:08 AM »

Are you seriously suggesting a Poisson distribution claiming that the event of a file not being in the disk anymore and the event of someone reaching the top of the queue FOR THAT FILE, WHICH IS NOT THERE, are not correlated?

Have you done your homework before posting?
Oh, I did my homework on this very specific topic plenty of times.

Let's put some formalities.
There's no event "file not in disk anymore". There IS event "I checked if file is there and result is false". Despite being similar, this is not the same.

One of ways to describe Poisson distribution is time you spend on bus station before bus arrives. You CAN choose WHEN to come to station, but this WILL not change distribution of T(t) - time spent in waiting. This relies on assumption that event "bus come to station" and "you come to station" are RARE in INDEPENDENT.

Same thing here. You have following events:
a. File deleted from disk
b. Share reloaded
c. Client enters queue
d. Client reach top of queue but file is not there.


The claim is that correlation between P(b) and P(c) is very small, because P(a), P(b) are both small. Moreover, once Corr{P(d|c),P(b)}=0 since share reloading doesn't affect clients already in queue.
Now, let's also consider the fact, that (d) => (b) (share automatically reloaded once some client hit top of queue). So, you have MANY clients; but it's enough that only ONE hit top of queue to reload shares. This means that F(b|c) -> 1 and it doesn't matter very match whether you hit "reload" manually or not.
« Last Edit: November 04, 2008, 12:07:36 PM by lfroen »
Logged
Pages: 1 [2]