Jump to content

"Corked" jobs?


ciaobaby

Recommended Posts

Posted

I've asked this question in passing before, now it is direct.

What DOES "corked jobs" actually mean by your definition, I know what I would expect "corked" to mean but I can't see what the BitTorrent developers or UI designers mean.

OR

Is it that are you using "corked" as a euphimism, when you really mean "bottle necked" jobs?

Posted

That's the number of jobs that are waiting on other jobs.

If the "corked" jobs in the disk statistics pane grows and stays for a while, the disk job column tell you what kind of fence job they are waiting on, and which torrent is causing it of course. This column is a debugging tool ,it's a way to get insight into what takes time in the disk I/O.

Seeing nothing in this column is a good sign. If you see something stuck in this column for a long time, it means the disk system is totally overloaded, or that uT has a logic / threading error in the disk system.

I've never seen anything in neither of those, even if I disable both caches, and get disk overload in seconds (@~600K DL speed, which is weird too...).

  • 2 weeks later...
Posted
If the "corked" jobs in the disk statistics pane grows and stays for a while, the disk job column tell you what kind of fence job they are waiting on, and which torrent is causing it of course. This column is a debugging tool ,it's a way to get insight into what takes time in the disk I/O.

[...]

I've never seen anything in neither of those, even if I disable both caches, and get disk overload in seconds (@~600K DL speed, which is weird too...).

I'll hijack this thread and provide an example using 3.3.2 build 30260:

qVYpOj3.png

Comment 1: I don't get any hits when I search the forum for JT_FIXPARTFILE.

Comment 2: Disk I/O settings, including advanced, are all at their defaults.

Comment 3: In this current state, I'm not able to upload either.

Comment 4: I test a new 3.x build every month or so, but end up reverting to 2.2.1 because this behavior (bug?) makes uT 3.x unusable for me. This behavior doesn't occur on every download, but within 1-2 days of trying the new build generally.

Comment 5: On some older 3.x.x builds something similar would happen, but instead of "128MB of 128MB cache used", I'd e.g. get "2GB of 128 MB cache used" on a 2GB torrent, along with 2GB memory usage (my report). At least the "overfull buffer" appears to be be fixed in 3.3.2 build 30260.

Posted

And this is what it *should* look like:

dd152a287998854.jpg

You are simply not writing to disk. Access issues? ran-as-admin for testing? FAT32 issue? who knows... but you need to see what's blocking your system's IO for this new exe ...

Posted
And this is what it *should* look like:

http://thumbnails104.imagebam.com/28800/dd152a287998854.jpg

You are simply not writing to disk. Access issues? ran-as-admin for testing? FAT32 issue? who knows... but you need to see what's blocking your system's IO for this new exe ...

Yeah that looks like what I'm getting with pre-new-io-cache-system builds. I'm running as admin, NTFS, and two hours earlier the 3.3.2 build wrote to the disk just fine...
Posted
two hours earlier the 3.3.2 build wrote to the disk just fine...

So, just rewind your clock... :P Or restore to your previous Windows restore-point...

Posted
two hours earlier the 3.3.2 build wrote to the disk just fine...

So' date=' just rewind your clock... :P Or restore to your previous Windows restore-point...[/quote']Or maybe a a time machine? :D But seriously though, after closing and restarting, uT 3.3.x will work perfectly for a while (minutes, hours, days, depends) until the i/o system breaks again. Back to 2.2.1 I go until, for now at least. Since JT_FIXPARTFILE gives zero search hits, maybe it's worth posting this in the bug reports section?

Posted

I'll repost this seeing as it has mysteriously disappeared.

That's the number of jobs that are waiting on other jobs.
I know what they are.

It is the incorrect terminology I am questioning.

Posted
I didn't get it - what is JT_FIXPARTFILE ? where do you see that code?
the disk job column tell you what kind of fence job they are waiting on, and which torrent is causing it of course. This column is a debugging tool ,it's a way to get insight into what takes time in the disk I/O.
The disk job column shows JT_FIXPARTFILE on downloading torrents when the i/o stops working, see my screenshot above.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...