"pre-buffer Upload" Nice to save HD...
#1
Posted 01 April 2006 - 08:45 AM
I'm reading/studying the sourcecode and and i idea came out of the hat... why not buffering in memory much more data to upload? (one more slot for eachone in queue).
The idea was to save hard disks... i know about the filebuffer,but it only saves against the "write to disk operation", hard disks will never turn off.
I've tryed to set filebuffer to 25 meg,recompiled emule,set 1 min to shut down hard disk in the power manager of windows, but the hard disk never shut down (i've a clean windows installation on a dedicated machine).
#2
Posted 01 April 2006 - 09:02 AM
Shutdown/powerup cycles are more stress to them than anything i can come up with right now.
Ok, maybe using them regularily in harddisk throwing contests...
The point is, a reading buffer to reduce disk access would not do any harm, but harddisks already have memory buffers (up to 16 MB for the newest models).
It certainly wouldn't hurt to have one in emule, if optional. At the moment i see only users with high upload speeds benefit from this, but not the regular user.
P2P is not piracy, it's marketing.
In fact, if your music or movie is NOT being downloaded, you should be WORRIED !
If you can't even give it away for free, how do you expect to sell it, stupid ?
#3
Posted 01 April 2006 - 10:23 AM
OK for me
P.S.
I suggest this for releasers:
http://techreport.co...am/index.x?pg=1
#4
Posted 01 April 2006 - 11:53 AM
#5
Posted 01 April 2006 - 01:50 PM
#6
Posted 01 April 2006 - 04:30 PM
You want a light mod with source-dropping, Powershare and WiZaRd's ClientAnalyzer ?
Try Spike2-Mod !
You rather want to stick to official eMule but don't want to miss all the new fixes and optimizations from the mods ?
Try OfFixed-Mod !
This post has been edited 1 time, the last time by God: Tomorrow, 12:74 PM
#7
Posted 02 April 2006 - 06:54 PM
#8
Posted 03 April 2006 - 10:58 AM
the filebuffer is only thought for WRITING access not for reading access.
For every client in your upload eMule allocates a buffer which is filled and checked in
void CUpDownClient::CreateNextBlockPackage()
but the cache in official client is pretty low, it allocates a max of 15secs @ 3.5kB/s - if you raise the upload speed then you should adapt that buffering, too. If you have REALLY a lot of memory then you could read in a whole chunk right on startup of each upload session (not considering CPU now!)
I changed that part for iONiX and others to
Quote
//hmmm official code would upload @3.5kB/s to every client... that's about 15sec cache
const uint32 cache = max(15*GetDatarate(), 150*1024);
//<<< WiZaRd - caching
// See if we can do an early return. There may be no new blocks to load from disk and add to buffer, or buffer may be large enough already.
if(m_BlockRequests_queue.IsEmpty() // There are no new blocks requested
|| m_addedPayloadQueueSession > GetQueueSessionPayloadUp()
//>>> WiZaRd - caching
//&& m_addedPayloadQueueSession - GetQueueSessionPayloadUp() > 50*1024
&& m_addedPayloadQueueSession - GetQueueSessionPayloadUp() > cache
//<<< WiZaRd - caching
) // the buffered data is large enough already
return;
...
...
// Buffer new data if current buffer is less than 100 KBytes
while (!m_BlockRequests_queue.IsEmpty()
ReadBlockFromFileThread
//>>> WiZaRd - caching
//&& (m_addedPayloadQueueSession <= GetQueueSessionPayloadUp() || m_addedPayloadQueueSession-GetQueueSessionPayloadUp() < 100*1024)
&& (m_addedPayloadQueueSession <= GetQueueSessionPayloadUp() || m_addedPayloadQueueSession-GetQueueSessionPayloadUp() < 2*cache)
//<<< WiZaRd - caching
)
To allocate a 15sek buffer regardless of the uploadspeed.
#9
Posted 03 April 2006 - 12:01 PM
There is no way to buffer more data, until emule changes the protocol.
Edit:
you can try morph.. it buffers all requested blocks, not looking at any buffersize.
This post has been edited by Xman1: 03 April 2006 - 12:06 PM
#10
Posted 03 April 2006 - 12:31 PM
#11
Posted 03 April 2006 - 06:46 PM
I have a simple 32KB/s line (capped at 28KB/s) and I use slotfocus (so I often upload at more then 20KB/s to a single client).
#12
Posted 03 April 2006 - 09:40 PM
CiccioBastardo, on Apr 3 2006, 07:46 PM, said:
Works for me.
#13
Posted 05 April 2006 - 05:16 PM
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
#14
Posted 05 April 2006 - 06:50 PM
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
#15
Posted 05 April 2006 - 07:46 PM
FAQ, on Apr 3 2006, 01:40 PM, said:
Math is delicious!
MmMm! Mauna Loa Milk Chocolate Toffee Macadamias are little drops of Heaven ^_^
Si vis pacem, para bellum DIE SPAMMERS DIE!
#16
Posted 05 April 2006 - 08:38 PM
PacoBell, on Apr 5 2006, 08:46 PM, said:
The worst thing is the heat generation from eight computers and one hdd rack.
#17
Posted 16 April 2006 - 04:38 PM
Quote
It already has a minimal buffering of 180k, since it reads file data in 180k blocks, and then compresses them(entire block must be available prior to compression).
180k is large enough, since even at that size there's a chance that the buffered data would be swapped out to disk, losing everything you were trying to save by using buffering.
Anyway, if you want more buffering, you can try starting here:
Quote
(m_addedPayloadQueueSession <= GetQueueSessionPayloadUp() || m_addedPayloadQueueSession-GetQueueSessionPayloadUp() < 100*1024)) {
Still, by increasing this number, you increase the chance of memory swap, which would bring back harddrive usage.
Remember, physical memory may be fast, but it has limited size.
SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.
#18
Posted 19 April 2006 - 05:04 PM
As sais, slotfocus is the ideal companion for this feature.
#19
Posted 04 September 2006 - 03:07 PM
eMule is meant to be running 24/7 at best - but most standard harddisks aren't!
A big memory buffer, fitting todays RAM capacities, wouldn't only reduce noise, it would also increase your harddisks lifetime!
This post has been edited by Semm: 04 September 2006 - 03:08 PM
#20
Posted 06 September 2006 - 05:19 PM
Motor ignition is a more critical factor (that is, if you keep starting and stopping them very often they'll die much sooner than leaving them spinning freerly).
I have a 120GB Maxtor that has been spinning 24/24 365/365 (but power cutoffs or during rare lighting storms) for the last 3 years, under the so "heavy" eMule load. Lately had some problems, I reformat it Low Level and it now seems working OK.
Keep your HDs cool and they'll enjoy spinning for years.