Cache tijden

[alias haha]

Ik gebruik geen cache ex, maar ik zie her verschillende cache tijden, bv:

 

User 1 staat bijvoorbeeld op op NED3, rechtstreeks op de kaart met een tijd van 320ms

User 2 pakt hem uit de cache met een tijd van 319ms

User 3 pakt hem uit de cache met een tijd van 319ms

En user 4 komt erbij en pakt hem uit de cache met een tijd van gemiddeld 30ms en deze tijd blijft zo ongeveer hangen, in ieder geval stukken lager dan user 2 en 3. Hoe kan dit zo verschillend zijn?

[Hotzenwalder]

Misschien helpt onderstaande uitleg je. Kijk eens bij de status of er staat 'cache1' of 'cache2'.

 

cache1 = has already been found by the server module in the cache.

(the process that keeps the connection to the client)

cache2 = was then already in the queue and processing was

by the reader module found in the cache.

 

cache1 can occur only if the dcw at the request already exists

and this in turn can only happen even if an inquiry comes much later, when the inquiry that it has brought into the cache.

 

1. runs with a sender box1, box2 runs with sender b. I zap with box1 to sender b. (cache1)

-> The client process is already in the inquiry unsupervised way (without reader-process), the CW in cache and responds.

for this case is the parameter cache delay, because for me it seemed every now and then, that if the server immediately antortet,

it is not always the camd "processed" has (black screen). with 20 ms I never had problems.

 

2. 2 boxes running a long time on the same sender. (cache2)

-> Ask almost simultaneously from both boxes, the new CW. neither of the two client processes found in the cache and the CW

push the inquiry into the queue for reader process. This works squentiell from the queue.

CW, the first he has to map or identify remote-server "," work off at the request of the second, he notes

CW NOW that the course is in the cache and only has one more "done" signal.

for this case occurs, the cache delay of course NOT power, because the second process, the waiting time of the first request

necessarily had.

23 april 2012 aangepast door Hotzenwalder

[Tonskidutch]

" don't shoot the messenger "

in dit geval dus wel, daar de uitleg nog kant noch wal raakt voor een doorsnee lezer.

men heeft toch wel een betere uitleg nodig dan dat citaat Hotzenwalder.

 

ciao

[alias haha]

Cache 1 is als je in een zender komt tijdens het zappen die in de cache staat, dan zijn je cache tijden 0 tot 20ms.

Cache 2 is als je in de cache blijft hangen van een bepaalde zender, dan is de tijd ongeveer net zo snel als diegene die zender als eerste benut, die hem dan van de kaart haalt.

En als je cache ex gebruikt word het vanzelf cache 3, heb ik gemerkt, mocht je van de ene oscam naar de andere oscam een cache cw versturen.

Maar ik zie nu dat de zogenaamde user 4 zoals hierboven geschreven staat gewoon in cache 2 hangt, maar toch nog snellere tijden heeft dan user 2 en 3.

Heb er verder geen problemen mee, maar het valt op...