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
