1 |
P.V.Anthony posted <4364E65D.4070109@×××××××××××.sg>, excerpted below, on |
2 |
Sun, 30 Oct 2005 23:27:25 +0800: |
3 |
|
4 |
> specs and observations. |
5 |
> |
6 |
> Specs. |
7 |
> cpu: AMD 64 3000+ |
8 |
> drives: Sata drives |
9 |
> mobo: MSI Neo 4 Platinum |
10 |
> Ram: 2GB |
11 |
> Raid: Promise EX8350 |
12 |
> OS: Gentoo |
13 |
> Kernel: 2.6.13 r3 |
14 |
> Filesystem: XFS |
15 |
|
16 |
Now that I see that mobo listed... |
17 |
|
18 |
See the other threads currently active on the list/group right now. (You |
19 |
can read the list as either a newsgroup or a web forum, thru gmane.org. I |
20 |
use their list2news interface to read the list as a newsgroup. That way |
21 |
you can see posts from before you subscribed, if desired.) |
22 |
|
23 |
I haven't kept exact track but it seems I'm seeing that mobo mentioned in |
24 |
three different active threads ATM, this one included. The latest BIOS |
25 |
(1.B IIRC?) apparently has some rather major issues with recent kernels. |
26 |
The threads have been saying either revert to 1.9 (or whatever it was) or |
27 |
try an earlier kernel (2.6.11 or earlier, IIRC). They problems mentioned |
28 |
haven't been this one, but it's a troublesome combination in any case, so |
29 |
certainly read up, and consider reverting either the kernel or the BIOS. |
30 |
|
31 |
NOTE THAT ONE GUY ENDED UP FRYING HIS BIOS REVERTING, and had to buy a new |
32 |
chip ($10-ish, but he had to wait for it to be delivered). However, he |
33 |
was having issues getting into the BIOS already (the keyboard wasn't being |
34 |
activated soon enough to detect the delete to put it in BIOS edit mode), |
35 |
and it's possible the fried BIOS was related to that. |
36 |
|
37 |
The $10 isn't bad, so you might wish to order the spare BIOS chip and have |
38 |
it on hand before you try reverting, just in case. |
39 |
|
40 |
... As I said in a different thread, altho I understand it's changed a |
41 |
bit now, back when I was shopping for my dual Opteron board, it was |
42 |
between a Tyan and an MSI board. Visiting the MSI site, all their BIOS |
43 |
upgrades AND all their documentation was in MSWormOS executable format |
44 |
(I'm guessing self-extracting zip, but all I know is it had the .exe at |
45 |
the end). Tyan had the more traditional pdf docs and zip file BIOS packs. |
46 |
I emailed MSI and told them why they lost the sale. (The MSI board was |
47 |
cheaper and I would have likely gotten it if it looked like they cared at |
48 |
all about their Linux customers.) Maybe my mail was part of what made |
49 |
them decide to switch back to normal formats. |
50 |
|
51 |
Anyway, I've been quite impressed with Tyan -- they are quite responsive |
52 |
on the Linux front and regularly have Linux drivers, and even have |
53 |
customized lm_sensors configs for their boards. As well, many of them |
54 |
carry Linux certifications -- the manual for mine says Red Hat, SuSE, and |
55 |
Turbo Linux, all three, supported and certified. |
56 |
|
57 |
MSI OTOH, as I explained, I was rather disimpressed with, and the recent |
58 |
threads here on the list haven't helped. I consider myself lucky to have |
59 |
gone Tyan, and don't think I'll be considering MSI any time soon. |
60 |
|
61 |
> Observations. |
62 |
> When I was using the xfs I had the problem of the pauses in the tcp |
63 |
> transfers. These pauses, I am guessing is because of the pdflush that |
64 |
> occurs around every 20 seconds. There is only one pdflush every 20 |
65 |
> seconds. This caused lose of video frames when we did the video recording. |
66 |
> The video would have a jerk or jump when played back. |
67 |
> |
68 |
> I changed the dirty_ratio from the default of 40 to 5. This solved the |
69 |
> problem. During the recording preview there seems to be some jerks but |
70 |
> during the playback it seems to be ok. The pdflush happens more often and |
71 |
> there is still one pdflush. I think the jerk that I see in the record |
72 |
> preview coincides with the pdflush. More jerks in record preview but ok |
73 |
> during playback. |
74 |
> |
75 |
> Next I formatted the drives to the ext3 filesystem. The dirty_ratio was |
76 |
> set back to the default value of 40. When the video started to record |
77 |
> there is no loss of frames and no jerks in the preview window. During the |
78 |
> playback there is no loss. Everything is good. Check the top for pdflush |
79 |
> and noticed that the there is two pdflush. The pdflushs is happening at |
80 |
> every 5 seconds or so. Very fast compared to when I was using xfs. |
81 |
> |
82 |
> So the problem must be my xfs setting. For xfs I have only used the |
83 |
> default setting. Or could there be a problem with xfs and AMD64 kernel? |
84 |
> |
85 |
> What must I do to get xfs to work? Or what am I doing wrong? |
86 |
|
87 |
The dirty_ratio stuff you mention is beyond my level -- you know more |
88 |
there than I do by far, it would seem. I've only used reiserfs here, |
89 |
since I switched to Linux, as well, so can't say much about ext2/3 or xfs, |
90 |
beyond what's out there to read about them. I /can/ say I have two |
91 |
pdflush threads here, but I always figured that was one running on each |
92 |
CPU... |
93 |
|
94 |
Anyway, now that you mentioned the MSI Neo 4 Platinum mobo, with the other |
95 |
threads on it, I'd say the BIOS/kernel issues from that very likely are |
96 |
causing your issues as well. Address that, and there's a good chance your |
97 |
problems will disappear. In any case, there are several others on the |
98 |
list with that board to compare notes with, which should help. |
99 |
|
100 |
-- |
101 |
Duncan - List replies preferred. No HTML msgs. |
102 |
"Every nonfree program has a lord, a master -- |
103 |
and if you use the program, he is your master." Richard Stallman in |
104 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
105 |
|
106 |
|
107 |
-- |
108 |
gentoo-amd64@g.o mailing list |