Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#2148 closed Bug (invalid)

Scheduling problem

Reported by: blackjancsi Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.61
Severity: Normal Keywords:
Cc:

Description (last modified by charles)

Hey guys,

I stumbled upon the following problem. My goal was to set up the scheduler for workdays to run from 1 am to 6pm at full speed (300 K download, 24 K upload), with alt-speed, and 150 K download and 10 K upload otherwise (with speed...). Now seeing how today was a holiday, I was very happy to see that it did run at full speed at 10 am. However, when I then used the web interface to change them to lower values, to my suprise I found that:

  • the speeds changed in the clutch interface (to the values I set)
  • when I ran a test with transmission-remote -si (+auth params, but that's not relevant, I guess), it gave the same values as with clutch.

On the other hand, it still kept uploading at 24 K!!! This was visible in clutch, the upload speed varied between 16 and 24 K continuously. I might have misunderstood something, as I don't quite understand the use of the toggles (why is there an alt-speed-enabled AND an alt-speed-time-enabled - I mean, the only point in having an alt-speed-time is WHEN there is an alt-speed specified, right? From what I understood (as I did not find a page defining these new switches, btw, I am happy to write it for the wiki once someone explains them to me properly, and I would post an example file, too) I need to put all these to "true", or should it have been alt-speed-enabled FALSE??)

These were my params, see whether this is right or not (for what I wanted above):

    "alt-speed-down": 300,
    "alt-speed-enabled": true,
    "alt-speed-time-begin": 60,
    "alt-speed-time-day": 62,
    "alt-speed-time-enabled": true,
    "alt-speed-time-end": 1080,
    "alt-speed-up": 24,
 
    "speed-limit-down": 150,
    "speed-limit-down-enabled": true,
    "speed-limit-up": 10,
    "speed-limit-up-enabled": true,

ps 1: my system is a WD MyBook? World II headless unit, I run transmission 1.61 from optware on it (that I installed OVER the old 1.52 version, though as all I see are the 3 binaries transmission-daemon, transmission-remote, and transmissioncli, so I don't see how an uninstall-install would have been different - but I might be wrong here) ps 2.: what happens when the scheduler should change the speed, but clutch is still open in a browser (displaying a value, e.g. 100 D, 5 U ?)

ps 3.: I would suggest a parametrisation that is based on arrays, e.g. weekdays 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0, etc, such as proposed in the torrent_watchdog script by frater, as it is more flexible: http://mybookworld.wikidot.com/forum/t-143349#post-496015 ).

Change History (19)

comment:1 Changed 13 years ago by blackjancsi

Oh crap. I am sorry about the lack of formatting, will do better next time.

Now on to report the lack of watch functionality...

comment:2 Changed 13 years ago by charles

  • Description modified (diff)

comment:3 Changed 13 years ago by charles

How are you invoking transmission? Are you running the daemon, the cli, the gtk client, the qt client, or what?

comment:4 Changed 13 years ago by blackjancsi

I run a script: /etc/init.d/transmission start (which launches the daemon with some parameters - e.g. that I want authentication, the password and username itself, etc. It then runs a few transmission-remote commands - working directory, port, etc). I took it from here: http://kyyhkynen.net/stuff/mybook/torrent_transmission.php Let me know if you need any further info!

comment:5 Changed 13 years ago by charles

if you run the daemon by hand, do the limits work?

what is the location of the settings.json file that you're using?

this sounds like a configuration problem, but I don't see the cause yet.

comment:6 follow-up: Changed 13 years ago by charles

also I suggest connecting to the daemon with the Qt client so that you can look at it firsthand and see what the alt speed settings are. I don't think the web client supports the alt speeds yet.

comment:7 Changed 13 years ago by charles

So, random thoughts so far:

  • first off, you're running transmission from an unsupported script, so I don't know what that's bringing into the mix.
  • please run "/transmission-remote --debug -si" and pastebin the debug output so that we can see what the running daemon's alt speed limit settings are.
  • are you sure you're editing the correct settings.json? the default one is ~/.config/transmission-daemon, so the question is, what user is the daemon running under -- yours or root?
  • does the script specify a different configuration directory anywhere with -g?
  • do the alt speeds work when you start transmission-daemon by hand, the same way the watchdir worked when you started it by hand?
  • this is looking less and less like a transmission bug and more like a configuration problem.

comment:8 in reply to: ↑ 6 Changed 13 years ago by blackjancsi

Replying to charles:

also I suggest connecting to the daemon with the Qt client so that you can look at it firsthand and see what the alt speed settings are. I don't think the web client supports the alt speeds yet.

I don't think I can do that, as the system does not have a graphics card and I don't have a simple Hardware-to-screen interface like this one here http://www.microvga.com/... If this is not the case, let me know and I'll be happy to try it out (it is not installed for the moment, btw, unless transmissioncli does this - but how would it run without a graphic card?) The problem might partially be that I am not 100% sure what I have on my system - I installed it via Optware - which gives the version that runs on my system, I suppose.

comment:9 Changed 13 years ago by charles

What about my other suggestions and questions?

comment:10 Changed 13 years ago by blackjancsi

  • Component changed from Transmission to Daemon

Hi,

sorry, I wrote the previous from work. Before falling to bed, a few reactions:

first off, you're running transmission from an unsupported script, so I don't know what that's bringing into the mix.

It is quite similar to yours and not to complicated, have a look here: My startup script

please run "/transmission-remote --debug -si" and pastebin the debug output so that we can see what the running daemon's alt speed limit settings are.

Here goes the output:

[root@MarkiWD64 ~]# transmission-remote --debug -si --auth=*user*:*passwd*
posting:
--------
{"arguments":{},"method":"session-get","tag":0}

--------
> POST /transmission/rpc HTTP/1.1
User-Agent: transmission-remote/1.61 (8420)
Host: localhost:9091
Accept: */*
Accept-Encoding: deflate
Content-Length: 48
Content-Type: application/x-www-form-urlencoded

< HTTP/1.1 401 Unauthorized
< Server: Transmission
< WWW-Authenticate: Basic realm="Transmission"
< Date: Tue, 02 Jun 2009 21:34:23 GMT
< Content-Length: 43
< Content-Type: text/html; charset=ISO-8859-1
<
> POST /transmission/rpc HTTP/1.1
Authorization: Basic dHJhbnNtaXNzaW9uOmQ4NmQ2ZThRMmY=
User-Agent: transmission-remote/1.61 (8420)
Host: localhost:9091
Accept: */*
Accept-Encoding: deflate
Content-Length: 48
Content-Type: application/x-www-form-urlencoded

< HTTP/1.1 409 Conflict
< Server: Transmission
< X-Transmission-Session-Id: FKLQOLjeDR2ib99wKI3EVZpifVH5KtWp8fwiP3f1BAl3Jfv8
< Date: Tue, 02 Jun 2009 21:34:23 GMT
< Content-Length: 762
< Content-Type: text/html; charset=ISO-8859-1
<
posting:
--------
{"arguments":{},"method":"session-get","tag":0}

--------
> POST /transmission/rpc HTTP/1.1
User-Agent: transmission-remote/1.61 (8420)
Host: localhost:9091
Accept: */*
Accept-Encoding: deflate
X-Transmission-Session-Id: FKLQOLjeDR2ib99wKI3EVZpifVH5KtWp8fwiP3f1BAl3Jfv8
Content-Length: 48
Content-Type: application/x-www-form-urlencoded

< HTTP/1.1 401 Unauthorized
< Server: Transmission
< WWW-Authenticate: Basic realm="Transmission"
< Date: Tue, 02 Jun 2009 21:34:23 GMT
< Content-Length: 43
< Content-Type: text/html; charset=ISO-8859-1
<
> POST /transmission/rpc HTTP/1.1
Authorization: Basic dHJhbnNtaXNzaW9uOmQ4NmQ2ZThRMmY=
User-Agent: transmission-remote/1.61 (8420)
Host: localhost:9091
Accept: */*
Accept-Encoding: deflate
X-Transmission-Session-Id: FKLQOLjeDR2ib99wKI3EVZpifVH5KtWp8fwiP3f1BAl3Jfv8
Content-Length: 48
Content-Type: application/x-www-form-urlencoded

< HTTP/1.1 200 OK
< Server: Transmission
< Content-Encoding: deflate
< Content-Type: application/json; charset=UTF-8
< Date: Tue, 02 Jun 2009 21:34:23 GMT
< Content-Length: 332
<
got response (len 706):
--------
{"arguments":{"alt-speed-down":300,"alt-speed-enabled":false,"alt-speed-time-begin":60,"alt-speed-time-day":62,"alt-speed-time-enabled":true,"alt-speed-time-end":1080,"alt-speed-up":24,"blocklist-enabled":false,"blocklist-size":0,"download-dir":"\/shares\/internal\/PUBLIC\/downloads","encryption":"tolerated","peer-limit-global":240,"peer-limit-per-torrent":60,"peer-port":51413,"peer-port-random-on-start":0,"pex-enabled":true,"port-forwarding-enabled":true,"rpc-version":6,"rpc-version-minimum":1,"seedRatioLimit":1.2000,"seedRatioLimited":true,"speed-limit-down":100,"speed-limit-down-enabled":true,"speed-limit-up":20,"speed-limit-up-enabled":true,"version":"1.61 (8420)"},"result":"success","tag":0}

--------
VERSION
  Daemon version: 1.61 (8420)
  RPC version: 6
  RPC minimum version: 1

TRANSFER
  Download directory: /shares/internal/PUBLIC/downloads
  Portforwarding enabled: Yes
  Encryption: tolerated

LIMITS
  Peer limit: 240
  Downloadlimit enabled: Yes
  Downloadlimit:    100 KB/sec
  Uploadlimit enabled:   Yes
  Uploadlimit:       20 KB/sec

as you can see, it still sticks to the 100 D - 20 U I set yesterday night, despite the fact that the scheduler should have changed this to 150 - 10 at 18:00 this evening (it is 23:37 right now) This means that it rewrote my config file - I guess I need to write a script which sets all these values right once I have not given commands through the web interface for some time (Maybe a button that toggles scheduling ON/OFF, if ON, the speed in clutch is irrelevant, if OFF, it is the only thing that matters) I guess the "alt-speed-enabled":false should be on true as well (did that get set to "false" automatically when I set some value in clutch?

are you sure you're editing the correct settings.json? the default one is ~/.config/transmission-daemon, so the question is, what user is the daemon running under -- yours or root?

I have not changed the location of the settings file, it is still in /root/.config/transmission-daemon/settings.json . The daemon is running under root, I know this is stupid, but I was too lazy to set it up with its own user yet. (as yet, I don't even know how to have a program start up during boot by a user that is NOT root). Sorry, I am quite a linNoob. :-s

does the script specify a different configuration directory anywhere with -g?

No.

do the alt speeds work when you start transmission-daemon by hand, the same way the watchdir worked when you started it by hand? this is looking less and less like a transmission bug and more like a configuration problem.

I'll experiment with this tomorrow, and yes, you are probably right - the problem is my lack of understanding of the parametrisation of the program. To a daft half-XP half Linux guy like me, some sample config scripts for the scheduling would have gone a long way - I have read both the transmission-daemon and transmission-remote man pages, have looked through the init.d script proposed on the site Init.d script, but I did not get there just yet.

Further Noob questions

  • In the init.d script, there are the two lines:
    # Read configuration variable file if it is present
    [ -r /etc/default/$NAME ] && . /etc/default/$NAME
    
    # Load the VERBOSE setting and other rcS variables
    [ -f /etc/default/rcS ] && . /etc/default/rcS
    

But difficult for me to use them to define my params without seeing what these files should look like.

  • Transmission-remote only has the -u and -d commands ("global up/download speed"), but what does that mean in terms of the four json parameters ("alt-speed-down","alt-speed-up","speed-limit-up","speed-limit-down")?
  • Is the switch "alt-speed-enabled" the one that enables (true) or disables scheduler functionality (if on, toggles between speed and alt-speed, if off, stays on speed)? In this case, does setting a new speed in clutch automatically mean that this gets toggled back to "alt-speed-enabled:false"?
  • Remark: As I have a headless machine, I only have this transmission-related directory in .config: $HOME/.config/transmission-daemon
  • Supposing I were to take over your init.d script - can you send me a sample variable definition file, please?

Thanks for the help, the great program, and all the fish of course!

comment:11 Changed 13 years ago by blackjancsi

I am not sure how clear this was from all that was said so far, so I would like to reiterate:

Transmission is running on my NAS storage (WD MyBook? World Edition II, running a Debian derivative Linux with Busybox, no keyboard or graphics card on it). This means that usually, the daemon is running, and that's all. All "normal" interaction should be confined to using clutch for status monitoring from another PC on the local network, and dropping files into the watch folder (also from other PCs).

I use an ssh terminal to edit the config file (once I stopped the daemon) or the startup script, but once it is setup, I would like it to work in the way described above.

comment:12 Changed 13 years ago by blackjancsi

Oh crap, I could not stop... 0:47 by now... So, I stopped the daemon. Then I set the following parameters:

    "alt-speed-down": 300,
    "alt-speed-enabled": true,
    "alt-speed-time-begin": 30,
    "alt-speed-time-day": 62,
    "alt-speed-time-enabled": true,
    "alt-speed-time-end": 1080,
    "alt-speed-up": 24,
...
    "speed-limit-down": 150,
    "speed-limit-down-enabled": true,
    "speed-limit-up": 10,
    "speed-limit-up-enabled": true,

And restarted it again. Output:

[root@MarkiWD64 torrents]# transmission-remote -si --auth=*user*:*passwd*
...
LIMITS
  Peer limit: 240
  Downloadlimit enabled: Yes
  Downloadlimit:    150 KB/sec
  Uploadlimit enabled:   Yes
  Uploadlimit:       10 KB/sec

So I am in my "normal" (non-alt-timed) state. Why does the scheduling not work now?!

  • "alt-speed-time-begin": 30 - so alt-speed should start @0:30 - it is 0:47, and it is still using the regular speed-limit-down/up.
  • Am I getting this all wrong? Should I have set both "speed-limit-up-enabled" and "speed-limit-down-enabled" to false manually, and have "alt-speed-enabled": true, and then wait for it to toggle over to the other state at 18:00 (that is "alt-speed-time-end": 1080)? If this is the case, why isn't there a single switch that's called scheduling-active: true/false??? Aaaaaargh, this is driving me maaaaad...

comment:13 follow-up: Changed 13 years ago by blackjancsi

Tried the latter, did not work. I have reached a dead end. (sigh)

comment:14 in reply to: ↑ 13 Changed 13 years ago by blackjancsi

Replying to blackjancsi:

Tried the latter, did not work. I have reached a dead end. (sigh)

That is, despite the fact that both "speed-limit-up-enabled" and "speed-limit-down-enabled" were on false, it keeps using their values... (150 D, 10 U, instead of the 300 D, 24 U that I would want here).

comment:15 Changed 13 years ago by blackjancsi

OK, so right now, this difference between displayed and real speed still shows: this is the status + the running torrents' state:

[root@MarkiWD64 ~]# transmission-remote -si --auth=*user*:*passwd*
VERSION
  Daemon version: 1.61 (8420)
  RPC version: 6
  RPC minimum version: 1

TRANSFER
  Download directory: /shares/internal/PUBLIC/downloads
  Portforwarding enabled: Yes
  Encryption: tolerated

LIMITS
  Peer limit: 240
  Downloadlimit enabled: Yes
  Downloadlimit:    150 KB/sec
  Uploadlimit enabled:   Yes
  Uploadlimit:       10 KB/sec
[root@MarkiWD64 ~]# transmission-remote -l --auth=*user*:*passwd*
ID     Done       Have  ETA           Up    Down  Ratio  Status       Name
   1   100%     4.0 GB  Done         7.9     0.0   0.19  Seeding      Torrent 1
   2   100%     3.8 GB  Done        13.8     0.0   0.29  Seeding      Torrent 2
   3   100%    34.6 MB  Done         2.3     0.0   0.88  Seeding      Torrent 3
Sum:            7.8 GB              24.0     0.0
  • Clearly, it is uploading at the "full" alt speed (which is right, since we are in a scheduled fast period right now), but the question is: why does -si show the other speed (that clearly is not active at the moment)????
  • Also, those speed settings are the only ones (up- and download-limit) that can be accessed from clutch.

For reference, a debug output (again):

...
got response (len 705):
--------
{"arguments":{"alt-speed-down":300,"alt-speed-enabled":true,"alt-speed-time-begin":30,"alt-speed-time-day":62,"alt-speed-time-enabled":true,"alt-speed-time-end":1080,"alt-speed-up":24,"blocklist-enabled":false,"blocklist-size":0,"download-dir":"\/shares\/internal\/PUBLIC\/downloads","encryption":"tolerated","peer-limit-global":240,"peer-limit-per-torrent":60,"peer-port":51413,"peer-port-random-on-start":0,"pex-enabled":true,"port-forwarding-enabled":true,"rpc-version":6,"rpc-version-minimum":1,"seedRatioLimit":1.2000,"seedRatioLimited":true,"speed-limit-down":150,"speed-limit-down-enabled":true,"speed-limit-up":10,"speed-limit-up-enabled":true,"version":"1.61 (8420)"},"result":"success","tag":0}

Hmmmm, maybe I start to get it.

  • "alt-speed-time-enabled":true scheduling is ON
  • "alt-speed-enabled" toggles between alt (true) and normal (false) speeds

If this is right, then the needed actions are:

  • Documenting the scheduler (I am happy to do it, once someone confirms that this is the way it works)
  • Adding a few buttons to clutch (one toggling "alt-speed-time-enabled", which I would prefer to call scheduling-active, btw)
  • Adding a few lines of extra output to the -si command for transmission-remote, so that is shows the speed that is REALLY active at the given time (but also that scheduling is on, and that this is the ALT speed, etc)

Let me know.

comment:16 follow-up: Changed 13 years ago by charles

Documenting the scheduler (I am happy to do it, once someone confirms that this is the way it works)

alt-speed-time-day is a bitfield of the days of week. Start with zero. If you want sunday, add 1. if you want monday, add 2. if you want tuesday, add 4. if you want wednesday, add 8. if you want thursday, add 16. if you want friday, add 32. if you want saturday, add 64. congratulations, you now have alt-speed-time-day.

Adding a few buttons to clutch (one toggling "alt-speed-time-enabled", which I would prefer to call scheduling-active, btw)

This is in a separate ticket, #2157.

Adding a few lines of extra output to the -si command for transmission-remote, so that is shows the speed that is REALLY active at the given time (but also that scheduling is on, and that this is the ALT speed, etc)

That's in the nightly builds, ticket #2156.

If there are any action items left in this ticket, I don't see them.

comment:17 in reply to: ↑ 16 Changed 13 years ago by blackjancsi

Replying to charles:

Documenting the scheduler (I am happy to do it, once someone confirms that this is the way it works)

alt-speed-time-day is a bitfield, etc...


The question (comment:ticket:2148:15) was about the exact use of "alt-speed-time-enabled" and "alt-speed-enabled" - why did you explain the setting "alt-speed-time-day" (this one I know already from another source)??? If my summary is correct, then I propose that it gets written down somewhere along with all the OTHER params needed for scheduling (everything starting with alt- and its exact use, etc), preferably in the wiki. I know you must have a lot of stuff to do, so I proposed to do the work, once I perfectly understand it myself. That's all. Take it or leave it.

If there are any action items left in this ticket, I don't see them.


I think one more action item is missing, depending on whether I see things correctly or not (comment:ticket:2148:15). Transmission-remote only has 2 speed-related commands: -u and -d, which, just like the clutch web-interface, change the speed that is irrelevant in the alt-time- phase. I.e. one changes that speed, but it will keep running with the alt-speeds, which cannot be changed by these methods. Hence the only way to modify the relevant speed would be to stop the daemon, edit the json file and restart the daemon again. Hence I propose a set of new switches to transmission-remote, which would enable this functionality.

Unfortunately, for us under-resourced (RAM and/or CPU, not running the Qt or GTK+ client) headless system users, these are the natural control methods (transmission-remote and clutch), so those switches are sorely missed!

comment:18 follow-up: Changed 13 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

The alt-speed- flags should be better-documented in the Wiki

Good point. We already have a person who's supposed to be on top of things like this... I'll remind him about the alt- speeds.

transmission-remote doesn't let me set the alt speeds

Good. point. I've created ticket #2158 for this.

comment:19 in reply to: ↑ 18 Changed 13 years ago by blackjancsi

Replying to charles:

The alt-speed- flags should be better-documented in the Wiki

Good point. We already have a person who's supposed to be on top of things like this... I'll remind him about the alt- speeds.

transmission-remote doesn't let me set the alt speeds

Good. point. I've created ticket #2158 for this.



Thanks, I'll wait for the upgrades impatiently! (and explore the watch folder problem further)

Note: See TracTickets for help on using tickets.