[Stulle]

Yeah but unlike the official you can enable Slotfocus in your client or am I wrong there? This could mean all your available upload goes to a single client for indefinite time and I think that qualifies for a session ratio. anyway, this is just my opinion.

anyway, great picture! totally hits the nerve of this!

[Tuxman]

Stulle, on 27 Juli 2010 - 07:33 , said:

Yeah but unlike the official you can enable Slotfocus in your client or am I wrong there? This could mean all your available upload goes to a single client for indefinite time

That's what Slotfocus is for: Quickly spreading single releases completely.
The chance that single clients download from me "forever" is not so big, as I rarely spread an unlimited number of releases at a time.

Stulle, on 27 Juli 2010 - 07:33 , said:

anyway, great picture! totally hits the nerve of this!

Sure?

This post has been edited by Tuxman: 27 July 2010 - 05:42 PM

[James R. Bath]

Tuxman, on 27 July 2010 - 05:25 PM, said:

BTW Stulle, as the not existing session ratio is a part of the official eMule, I consider it as a feature, not as a bug. beba tries to be a "better" official client, nothing more.

My mod will try to be a better beba.


The official equation is facepalms=Stulle*c^2

[tHeWiZaRdOfDoS]

No, Stulle is right. The combination of SF and friendslot is bad by design. A friend could download forever with all other clients starving in queue/getting just a trickle slot - that's not what eMule was thought for.

[LorenzoC]

Friendslot is just one of the many contradictions in EMule. Like the credit system, ratio enforcing but limited under 10KB and so on. I guess all those topics have been discussed for million years now. It is all about your personal tolerance to incoherence.

But, from my point of view the difference between a "legal" client and an "illegal" one is just about "how much" of some feature it employs. Like it is approved to have some TFT but not too much, you can select clients with criteria A but not with criteria B, etcetera.

Once you can define what is good and what is not, you can also define when a client is better than Emule or not.

This post has been edited by LorenzoC: 28 July 2010 - 07:12 AM

[Stulle]

isn't it weird how every time James faces apparent defeat he speaks no word about it and tries to counter with something else he considers to be really clever and eventually he is wrong again?

anyway, Wiz and i explained why SF + FS is not that good and if Tuxman is gonna change it, fine, if he is not, there is no way to force him either. this is why i phrased this as a suggestion. although i do hope Tuxman will reconsider.

[James R. Bath]

tHeWiZaRdOfDoS, on 28 July 2010 - 07:27 AM, said:

No, Stulle is right. The combination of SF and friendslot is bad by design. A friend could download forever with all other clients starving in queue/getting just a trickle slot - that's not what eMule was thought for.

I'll interpret that as no Stulle is right, though that's probably racist to those disgraced with the same name. SF is disabled by default in beba and the reason I run beba has nothing to do with SF. It's that thing called a slot limiter, which is also missing from official and supposedly not what eMule was thought for. As for getting just a trickle slot, there's an easy solution to that which beba has also implemented. No trickle slots. As for ridiculous scenarios of friends downloading forever, the idea is to end the download faster so users you trust will get the file faster and be able to seed it with the rest bypassing any fakers and trickle or poorly configured and stalling mods that get in the way.

[Ejack79]

@Bath
You mean you need a community mod, right?

[Tuxman]

A friend slot already establishes a community.

[James R. Bath]

@Ejack79 I'm with Tuxman on this. Community mods are unnecessary, easily manipulated, and not as flexible as a good friend/friend slot implementation.

[Tuxman]

You probably misunderstood me here.

[Stulle]

oh, he does not bother understanding any more. he skips that part and proceeds to the part where he posts something insulting, stupid or downright retarded. this is of course unfortunate for any kind of discussion. anyway, Tux, as you are entirely right with that statement, does that mean you have reconsidered? anyway, i think Ejack was being ironic...

James, how about quitting this? you have proven how little you know about eMule and we are glad about it. no, seriously, we are not. we are not glad about some random moron spreading false assumptions, trolling on this board and ignoring any kind of common sense. why don't you do yourself a favor and either leave or get back to your senses? it's really kind of astonishing when a board member who has been around for years suddenly starts going wild like that. or is it that you just bought/got/hacked this account from the original James and now you are out for some fun? either way, you are a disgrace to the human kind!

This post has been edited by Stulle: 29 July 2010 - 08:06 AM

[dylandog84]

Hi everyone, maybe there is a tiny bug related to this improvement:

Quote

- improved: the speedguide link now has a hand cursor

taken from the latest changelog.

After a few tests, i discovered that the hand cursor isn't available for users with Vista and Seven.

[Tuxman]

Hmm, so maybe Vista and Seven use different cursors? Thank you for the hint, I'll investigate these days.

Stulle: Not sure yet.

[James R. Bath]

Why did you remove the ability to disable full chunk transfers?

[Stulle]

because cross-posting is bad and removing this option obviously is a statement against cross-posting. it's obvious, isn't it? on a more serious note, Tuxman might agree with Wiz and the Morph team that Full Chunk is the way to go.

[Tuxman]

... and with VQB and with all the other coders ...

Why do you want to disable Full Chunk transfer?

[LorenzoC]

If I remember it well, this is another of those old and neverending discussions about chunk completion and spreading strategies. Like you serve more people by rotating the queue faster versus you serve less people by serving each the 9.x Mega.
I guess the "full chunk" is all about "fairness" in serving everybody the same amount of data, regardless chunk completion, given they all have waited in the queue. But one could say it is better to complete more chunks in the same period instead of being "fair" and so it is perfectly legit to serve different amounts of data to different clients. Oh, there is also that thing so when you download a chunk you get parts from multiple sources so it is different from the past when each source served its own chunk... In theory source A sends 20% of "chunk 10" and 80% of "chunk 32" to reach the "full chunk". If I understood it correctly.

This post has been edited by LorenzoC: 07 August 2010 - 04:55 PM

[cemendur]

Two questions. What this try full chunk thingie exactly does? How someone with more than two fingers of forehead would had to put such a bad thing in Official eMule?

[LorenzoC]

"Transfer full chunks to all uploads" means you send always 9.x Mega of data to all clients you have in your queue.
Like I said above the reason for this behavior is about fairness, to treat all clients equally or if you prefer to pay/reward every client the same for the waiting time in your queue.

For example two clients wait 3 hours in your queue but the first one gets 1.5Mega only because that is all it takes to complete the chunk he requested and then (since he needs to request another chunk) he gets kicked out and need to start the queue from the bottom. The second client instead get 9Mega because he needs to download the whole chunk for completing.

With the feature enabled instead when the first client completes the chunk he requested with the first 1.5M transferred, he can still download more data (belonging to another chunk) to get the 9.x "full chunk" amount and so he gets the same as the second client.

Again, of course, if I understood it correctly.

This post has been edited by LorenzoC: 07 August 2010 - 09:50 PM