I replaced the 4.0 yuvfile with 3.1.
On 9/20/07, Bob Doolittle <[EMAIL PROTECTED]> wrote:
> Jimmy Fox wrote:
> > That did it. Everything seams to be running fast! Kent, this saved my
> > hide! Thank you...
> >
>
> What exactly did you do?
> Did you revert to an older version?
>
> That will solve the issue, although it will
> re-introduce a couple of much less severe bugs
> (one related to resetting a DTU that is displaying
> a YUV icon and one which caused the 26D OSD
> to appear on multihead secondaries when the primary
> is not available).
>
> The problem has been fixed and will go out
> in the first patch for 4.0.
>
> If you have a lot of YUV icons (see below for
> some scenarios that would cause this) I recommend
> reverting to the 3.1 version until the 4.0 patch
> is released. Both of the bugs mentioned above are
> primarily cosmetic.
>
> -Bob
>
>
> > On 9/19/07, Kent Peacock <[EMAIL PROTECTED]> wrote:
> >
> >> Bob Doolittle wrote On 09/19/07 09:12,:
> >>
> >>> Do you have a lot of sessions displaying yuv icons for some reason?
> >>> e.g. a card-only or pseudo-only policy, a lot of unrecognizable
> >>> smartcards inserted, a lot of token readers configured, or a lot of
> >>> multihead sessions where the primary isn't currently connected?
> >>>
> >>> The data indicating yuvfile problems is pretty sketchy at this point
> >>> and the problem is still under investigation. yuvfile never sends much
> >>> data, but if you have zillions of them running it's possible there
> >>> is an issue here.
> >>>
> >> Actually, it's not sketchy at all. I just took a look at a trace from
> >> Cards, and for each DTU, I see a continuous stream of N_SET_CURSOR
> >> commands (every 10 ms) for 2 DTUs in the trace. The signature of the
> >> command is such that it can only be coming from this function in yuvfile.c:
> >>
> >> static void
> >> send_cursor(nv_t nv)
> >> {
> >> unsigned char image[8*64];
> >> unsigned char mask[8*64];
> >> int color1 = 0;
> >> int color2 = 0;
> >>
> >> memset(image, 0, sizeof (image));
> >> memset(mask, 0, sizeof (mask));
> >>
> >> if (strcmp(setcursor, "null") != 0) {
> >> /* read cursor definition file goes here */
> >> fprintf(stderr, "%s: Cursor files are unimplemented\n",
> >> opt_progname);
> >> exit(2);
> >> }
> >>
> >> nv_set_cursor(nv, color1, color2, image, mask);
> >> }
> >>
> >> In other words, it's basically a blank cursor. Doing some math, at
> >> 1122 bytes per packet, 100 packets per second, each DTU is consuming
> >> about 900 Kbps of bandwidth - way more than the average when a session
> >> is running. It's pretty clear from looking at the main loop of the
> >> program that it will send the cursor every 10 ms. It's not even the
> >> repainting of the icon that is consuming the bandwidth.
> >>
> >> Kent
> >> _______________________________________________
> >> SunRay-Users mailing list
> >> [email protected]
> >> http://www.filibeto.org/mailman/listinfo/sunray-users
> >>
> >>
> > _______________________________________________
> > SunRay-Users mailing list
> > [email protected]
> > http://www.filibeto.org/mailman/listinfo/sunray-users
> >
>
> _______________________________________________
> SunRay-Users mailing list
> [email protected]
> http://www.filibeto.org/mailman/listinfo/sunray-users
>
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
