What's new

OScam Oscam acting like ecm loadbalancer

Ten Below

SuperTux
Staff member
Admin
Moderator
Messages
8,825
Joined
Sep 9, 2014
Reaction score
7,673
Points
628
This is an example how-to use loadbalancer function in oscam.
Understand that the LoadBalancer function is not just "a nice feature", its a minimal requirement to has this turned on, when you have multiple card-readers and/or proxy-readers.
Not doing so, will let Oscam forward ALL ECM requests to ALL available readers, something you won't like....

----

LB default

The settings in the LB Oscam in the oscam.conf [global] are:

Code:
Please, Log in or Register to view codes content!
First line "lb_mode" will enable LB. I advise to set "lb_save = 100" to limit load.

lb_mode - LB This is even activated. There are 5 settings under lb_mode.



  • lb_mode so is LB = 0 disabled (default)
  • lb_mode = 1 fastest reader first, there will always use the fastest reader (smallest response time)
  • lb_mode = 2 oldest first reader may be a bit confusing at first because the oldest reader. But is actually simple, because here are the requests sent alternately to the Reader. If you have two identical cards on first card request goes first request to the second card will not be very often so second card is older reader. If you got 3 card requests will be first card then turns to two then three, then again 1, 2, 3rd
  • lb_mode = 3 lowest usage level, here is an average response time of 5 ecm's is calculated and the reader is taken with the lowest utilization.
  • lb_mode = logging only 10, the LB is disabled but still collects statistics. Switched at some point of lb_mode eg "10" to "1", the LB knows the current fastest card, since he has diligently in the background creates the statistics.

lb_save - Default (no one uses "lb_save" line in the config) is "lb_save" disabled "0". By "lb_save" the collected statistics from the LB's are stored. So that it can access directly after restarting the server again Oscam it. The LB analyzed the response times of the cards, and these values are stored lb_save. After a restart of the LB Oscam now restore to these stored statistics. With "lb_save = 100" are stored every 100 ecm's that response times. 100 is minimum. You can also put more (200, 300 ....). Especially for very low-cpu devices that Oscam runs, maybe you should not store too often. Then provides a value of eg 500 ecm's.

lb_savepath stat = / tmp / .oscam / is default. Here you can adjust where the LB's Statistics collects. Default folder is actually well suited. But if one of its server (ie the device itself: PC, Dream or whatever) is often times reboots, / tmp is not suitable, since everything is what is in / tmp deleted at reboot.

I myself use lb_mode = 1, so I've done the best experience. lb_mode = 2 I would only recommend the people involved have no external reader, only with local cards. lb_mode = 3 is good: here I can also recommend it but I not prefer to use only my local cards. It will be so even if you have two identical cards in the server very often used external card, because they are perhaps more quickly. Just because my local card example, response times are just around the 150ms and an external card of a partner's share only 100ms, I still do not want that now uses the LB map of the Share Partners because it is faster 50ms. I personally think nothing of it because of a 50msec time savings is not a big deal. Everyone must know for himself.
Mode 3, I recommend only use if for example all share partners use Oscam and use all three LB fashion and know all about it. In Mode 2 LB can see how I said the only sense in it if you have no external card hooked as you will prefer my knowledge, no reader.

Reader preference for the LB

With lb_mode = 1, one can prefer certain reader (in the normal case, the local reader). This one does in the oscam.server. When the readers are to be preferred to come to the following:

Code:
Please, Log in or Register to view codes content!
Default is "lb_weight" to 100 The higher the value, the more the reader is preferred. I set for local readers "lb_weight = 300" and have all the external reader "lb_weight = 100". With lb_weight can (fake) quasi improve or deteriorate the ecm times the reader or. Therefore fake, because people are framing the LB better or worse times. It does not really the "original" ecm times of the Reader. The higher the "lb_weight" value is, the faster the ecm times one reader. The lower the value, the slower the ecm times one reader.

See here for an example of how latency is calculated and modified:

722px-Lb_weight_calc2.png

This allows you to adjust exactly how many milliseconds to the preferred reader should be improved. The red column with "100" is default (0 point) and it reflects only on "original" times - not tunned by hand. The down times are the actual times of upward Readers and upward over the values for lb_value (the fake times). At the point where the columns intersect, then the fake are times, after the change with lb_weight (apart from the red column, since these are the real time).

To illustrate better the table, look this example:


LB fallback setting

If you do not have Reader "fallback = 1" in the oscam.server can do that with active LB remove, since this is now ignored. In other words, is the response time of your card on time, eg 2.5 seconds, the LB moves to another card.
Code:
Please, Log in or Register to view codes content!
I have a very high value in it, it still remains up to 2.6 seconds on a map before switching to the next. Most use a value between 2000ms and 2500ms.

My personal recommendation (optional):

oscam.conf
Code:
Please, Log in or Register to view codes content!

oscam.server (Reader)
Code:
Please, Log in or Register to view codes content!
Expert Control

The following text is only for people who are familiar. Since the default values (which are automatically set when LB LB is active and no further settings are registered) are actually already perfect, you should definitely let the fingers, if you have no real reason to change these settings. Who does not know what he is doing should keep their hands off anyway.



  • lb_nbest_readers = X This allows you to specify how much of the best LB reader chooses. Default is 1
  • lb_nbest_percaid = caid1: count1, caid2: count2, 1702:2 The same as "lb_nbest_readers", only here you can adjust it for individual CAID separately. "Lb_nbest_readers" remains as a global setting and "lb_nbest_percaid" is set then for certain targeted CAID '.
  • How much lb_nfb_readers = X fallback Reader LB chooses. First default
  • lb_min_ecmcount = X After how many ecm's in the LB commits itself to a reader. Default is 5
  • lb_max_ecmcount = X After how many ecm's of LB again checked whether there is a better (faster) Reader. Default is 500
  • lb_reopen_seconds = X After how many seconds, the Reader is not answered, are requested again. Default is 900
  • lb_retrylimit = X (value is in milliseconds) can hereby prevent one of the LB after a while (lb_max_ecmcount) looks if there is a "better" reader. If the reader on which the LB was determined to continue to respond under 800ms, he seeks not only to a "faster" Reader. After default 500 ecm's of LB would send only once again to all readers with the right CAID's ECM to see if one is faster. As long as the old but weitehrin Reader responds to 800ms, the LB is at this. Default is 800
  • lb_retrylimits = CAID: time, 1702:900 The same as in retrylimit. Only here you can still make fine-tuning and specify for each CAID own times. So you can set both options, "retrylimit" generally and "retrylimits" CAID for certain (specific).
  • lb_stat_cleanup = hour after how many hours the statistics of the LBs will be deleted. Default = 336
  • lb_use_locking = 0 | 1 will activate when the ecm synchronized requests. Requests come so quickly and simultaneously pure, that the entry is not even in the ECM cache when the next one is already processed. Thus preventing this option to activate the ECM's are in the cache are sent repeatedly to the reader. But it may under certain circumstances, because multithreading is prevented, lead to higher response times. Default is 0
  • lb_noproviderforcaid = CAID1, CAID2 ... The LB automatically creates for each CAID Provider and the combination is requested statistics. This may prevent you herewith for certain CAID. The point is this: with HD 1830 + came from Camd3 for example (but do other emus) times inquiring about provider "000000", now over "003 411" or "008 011". Are you now in this function CAID 1830 to all inquiries about provider "000000" to be handled and there is so even statistics for 1830: 000000: xxxx. So one can keep his statistics smaller. Default nothing is set.
  • lb_reopen_mode = 0 | 1 Here, one defines how quickly blocked by LB readers are released. With "0", the reader after the specified time (lb_reopen_seconds) released. To set to "1" to reactivate the blocked reader quickly. Default = 0
  • lb_max_readers = limit If no statistics are available, or "lb_max_ecmcount" was reached, the LB checks the available readers whether they can open a channel and how quickly they can (ecm time). Either be sent to any reader with the correct CAID requests, or you have set a limit to how much the reader LB "annoying" maximum allowed. Default = 0 (unlimited).
  • If you activate this parameter must be one you no longer have to worry Beta tunnel entries in users | lb_auto_betatunnel = 0. The LB sends the CAID at 1834.1801 and 1835, a request to 1722 or at CAID 1833 1702 The CAID will then answer where first used. It will not duplicate requests sent out non-stop. Default is enabled this feature.

All credit to the original author turbopower
 

Top Bottom