In the context of NewCS, the effect of caching is to assist a card so it can better cope with the workload of multiple clients. A good caching system will handle more clients and eliminate glitches that would otherwise occur for various reasons such as clients rapidly channel surfing, tuning into an unsubscribed channel, etc.
Cache is where a processor keeps a copy of something locally rather than far away where it really belongs. It's like deciding to keep a six pack of beer in your lap rather than getting out of your chair and walking to the fridge for each one. Or like keeping some commonly used phone numbers in your wallet rather than looking them up in the phone book or internet each time you need to use them. Cache has the advantage of saving time and effort, but potential disadvantage of things getting out of date. The beer gets warm. The phone numbers may change without you knowing. The more stuff you keep locally the greater the risk of problem. Strategies and policies can be used to keep the tradeoffs in balance and prevent serious mistakes from happening. That involves planning and complexity, so caching is usually not done unless necessary - unless the consequences of not doing so are a problem.
NewCS has the job of managing ECM and EMM messages from multiple clients using (typically) only a single card. Some messages can be processed quickly but others take a substantial amount of time. If messages are simply queued up and fed to the card one at a time the card soon falls behind as the number of clients increases, becoming a bottleneck. Each answer must be supplied to a deadline otherwise glitches occur. Caching is about removing the bottleneck as much as possible. Many of the messages are essentially the same question being asked by different clients at the same time, so once the card has provided the answer it doesn't need to be asked again. Caching treats the card as an Oracle whose time is valuable and who is consulted only when needed, when the answer hasn't already been given.
Different message types need different policies. Some messages are questions that can be answered by paraphrasing what the card said when asked that question previously. The trick with those messages is recognising when the question has changed and needs to be referred to the card. At some point old answers aren't needed any more and a strategy is needed for deciding what information to keep, what to discard, and how to efficiently keep track of past questions and their answers. Other messages are advisories: information to be acknowledged and used in future. Sometimes the advisories might all need to be referred to the card, but duplicates may be too many to process and might need to be acknowledged without the card's help.
As you can see, caching usually requires an understanding of the meaning of the information being managed, the protocol by which they're sent and received, an awareness of time-sensitivity and priority, and a policy for dealing with errors such as incomplete or corrupt data, late arrival, unexpected duplicates, resending lost replies. The difference between a robust implementation and a flakey one is not usually how big the cache is but how carefully it handles errors.
NewCS stores its cache settings in its configuration XML file. Different images put configuration files in different places, and you can locate them using either the 'find' command in a terminal shell or by searching the forums for tips and tutorials applicable to your particular image.
In most cases the default NewCS cache values given in its sample configuration give the best results. Increasing the values will consume more RAM, possibly helping to reduce glitches in certain cases, but quite probably not. The default "auto" setting normally takes care of things. The main reason cache settings are offered for tweaking is because some providers may do unusual things, for example sending messages more frequently or rolling keys more often than the systems which the developer had access to for testing.
Bookmarks