Bitcoin Forum
December 06, 2016, 12:14:13 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251215 times)
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 06, 2012, 05:07:54 PM
 #1821

Which --icarus-timing option do I have to use with cgminer and the shortfin_icarus_cm1_test_150 bitstream to get a correct MH/s readout?

I don't use any timing options w/ the latest iteration of cgminer, and as long as none of the chips fail it's pretty accurate

ASIC miners available for purchase

Those who serve best, profit most.
1481026453
Hero Member
*
Offline Offline

Posts: 1481026453

View Profile Personal Message (Offline)

Ignore
1481026453
Reply with quote  #2

1481026453
Report to moderator
1481026453
Hero Member
*
Offline Offline

Posts: 1481026453

View Profile Personal Message (Offline)

Ignore
1481026453
Reply with quote  #2

1481026453
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481026453
Hero Member
*
Offline Offline

Posts: 1481026453

View Profile Personal Message (Offline)

Ignore
1481026453
Reply with quote  #2

1481026453
Report to moderator
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 06, 2012, 05:08:40 PM
 #1822

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.

Has anyone tested these yet?

ASIC miners available for purchase

Those who serve best, profit most.
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 06, 2012, 05:09:36 PM
 #1823

Which --icarus-timing option do I have to use with cgminer and the shortfin_icarus_cm1_test_150 bitstream to get a correct MH/s readout?

I think no one use this bitstream, but if you want to know the timing, just use short or long and read it yourself. Note it and then use it.

I would deffinitively use the latest bitstreams like "shortfin_dcmwd2_test_150.bit".

eb
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 06, 2012, 05:12:20 PM
 #1824

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.

Has anyone tested these yet?


Yes, that's the latest bitstreams and i use them, works very good.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 06, 2012, 06:53:22 PM
 #1825

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.

Has anyone tested these yet?

Currently running with the 190MHz bitstream on 2 boards with cgminer 2.5.0. The FPGA1 is regularly idle : orange light on and utility is low for one of the FPGA pairs :
Code:
ICA 0:                | 379.8/373.8Mh/s | A:1912 R:19 HW:0 U: 5.10/m
ICA 1:                | 380.5/377.0Mh/s | A:1078 R:10 HW:0 U: 2.88/m
ICA 2:                | 379.8/374.6Mh/s | A:1945 R:21 HW:0 U: 5.19/m
ICA 3:                | 379.9/375.2Mh/s | A:1629 R:19 HW:0 U: 4.35/m
0 and 2 seem fine, 1 and 3 are lagging behind and the ICA1 board clearly idles most of the time on FPGA 1.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 06, 2012, 07:30:00 PM
 #1826

Today, after looking at abcpool lagging I decided to test ozcoin as per ebereon message where he says that on ozcoin he had higher U: per boards.

These are my boards after 4 hours:

Code:
cgminer version 2.6.1 - Started: [2012-08-06 17:06:34]
--------------------------------------------------------------------------------
 (5s):7112.6 (avg):7433.5 Mh/s | Q:7095  A:22829  R:95  HW:0  E:322%  U:94.0/m
 TQ: 22  ST: 22  SS: 69  DW: 831  NB: 20  LW: 35096  GF: 11  RF: 1
 Connected to http://eu.ozco.in with LP as user
 Block: 000005cace1e77dd8a3dba11e7ceb0b8...  Started: [20:59:19]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 379.9/378.1Mh/s | A: 629 R: 2 HW: 2 U: 2.59/m
 ICA  1:                | 322.4/369.7Mh/s | A: 552 R: 6 HW:64 U: 2.27/m
 ICA  2:                | 379.7/365.3Mh/s | A:1233 R: 3 HW:76 U: 5.08/m
 ICA  3:                | 379.7/374.8Mh/s | A:1281 R: 3 HW:23 U: 5.28/m
 ICA  4:                | 370.3/362.5Mh/s | A:1153 R: 5 HW: 5 U: 4.75/m
 ICA  5:                | 363.2/362.7Mh/s | A:1144 R: 2 HW: 0 U: 4.71/m
 ICA  6:                | 379.9/377.7Mh/s | A:1315 R: 3 HW: 3 U: 5.42/m
 ICA  7:                | 379.6/376.7Mh/s | A:1335 R: 5 HW:15 U: 5.50/m
 ICA  8:                | 379.8/377.2Mh/s | A:1250 R: 7 HW: 6 U: 5.15/m
 ICA  9:                | 369.7/372.9Mh/s | A:1146 R: 7 HW:50 U: 4.72/m
 ICA 10:                | 379.7/377.1Mh/s | A:1220 R: 6 HW: 5 U: 5.03/m
 ICA 11:                | 379.8/378.0Mh/s | A:1306 R: 6 HW: 0 U: 5.38/m
 ICA 12:                | 355.8/355.9Mh/s | A:1090 R: 2 HW: 2 U: 4.49/m
 ICA 13:                | 351.4/355.5Mh/s | A:1153 R: 3 HW: 7 U: 4.75/m
 ICA 14:                | 379.8/377.5Mh/s | A:1268 R: 9 HW: 8 U: 5.22/m
 ICA 15:                | 379.8/377.8Mh/s | A:1313 R: 3 HW: 1 U: 5.41/m
 ICA 16:                | 379.7/362.2Mh/s | A:1207 R: 9 HW:87 U: 4.97/m
 ICA 17:                | 379.7/377.3Mh/s | A:1295 R:10 HW: 6 U: 5.33/m
 ICA 18:                | 379.9/378.4Mh/s | A: 629 R: 2 HW: 0 U: 2.59/m
 ICA 19:                | 379.8/378.1Mh/s | A:1313 R: 2 HW: 4 U: 5.41/m

Apart from a higher U: I've found that the number of hardware errors seems lower... today it's more cold here than every other day of the last week, but the HW: parameter is a lot lower.

I think that ozcoin lets the miner roll the time, see E: at 322%, so I've come to the conclusion that a good deal of HW: errors come from FPGAs hashing during the time that the miner is sending new work and so hashing mostly invalid data (trash in trash out Smiley)

This could be a reason for not having HW: increased by FPGAs since that number is not a real indicator of hardware problems when used with a FPGA.

On the other hand, while do FPGAs keep hashing when a new getwork is sent to them?

And, even more important, of the 87 errors of ICA16, how many of them are real errors and not errors due to hashing of a new, incomplete, getwork?

spiccioli.
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 06, 2012, 07:44:14 PM
 #1827

Today, after looking at abcpool lagging I decided to test ozcoin as per ebereon message where he says that on ozcoin he had higher U: per boards.

These are my boards after 4 hours:

Code:
cgminer version 2.6.1 - Started: [2012-08-06 17:06:34]
--------------------------------------------------------------------------------
 (5s):7112.6 (avg):7433.5 Mh/s | Q:7095  A:22829  R:95  HW:0  E:322%  U:94.0/m
 TQ: 22  ST: 22  SS: 69  DW: 831  NB: 20  LW: 35096  GF: 11  RF: 1
 Connected to http://eu.ozco.in with LP as user
 Block: 000005cace1e77dd8a3dba11e7ceb0b8...  Started: [20:59:19]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 379.9/378.1Mh/s | A: 629 R: 2 HW: 2 U: 2.59/m
 ICA  1:                | 322.4/369.7Mh/s | A: 552 R: 6 HW:64 U: 2.27/m
 ICA  2:                | 379.7/365.3Mh/s | A:1233 R: 3 HW:76 U: 5.08/m
 ICA  3:                | 379.7/374.8Mh/s | A:1281 R: 3 HW:23 U: 5.28/m
 ICA  4:                | 370.3/362.5Mh/s | A:1153 R: 5 HW: 5 U: 4.75/m
 ICA  5:                | 363.2/362.7Mh/s | A:1144 R: 2 HW: 0 U: 4.71/m
 ICA  6:                | 379.9/377.7Mh/s | A:1315 R: 3 HW: 3 U: 5.42/m
 ICA  7:                | 379.6/376.7Mh/s | A:1335 R: 5 HW:15 U: 5.50/m
 ICA  8:                | 379.8/377.2Mh/s | A:1250 R: 7 HW: 6 U: 5.15/m
 ICA  9:                | 369.7/372.9Mh/s | A:1146 R: 7 HW:50 U: 4.72/m
 ICA 10:                | 379.7/377.1Mh/s | A:1220 R: 6 HW: 5 U: 5.03/m
 ICA 11:                | 379.8/378.0Mh/s | A:1306 R: 6 HW: 0 U: 5.38/m
 ICA 12:                | 355.8/355.9Mh/s | A:1090 R: 2 HW: 2 U: 4.49/m
 ICA 13:                | 351.4/355.5Mh/s | A:1153 R: 3 HW: 7 U: 4.75/m
 ICA 14:                | 379.8/377.5Mh/s | A:1268 R: 9 HW: 8 U: 5.22/m
 ICA 15:                | 379.8/377.8Mh/s | A:1313 R: 3 HW: 1 U: 5.41/m
 ICA 16:                | 379.7/362.2Mh/s | A:1207 R: 9 HW:87 U: 4.97/m
 ICA 17:                | 379.7/377.3Mh/s | A:1295 R:10 HW: 6 U: 5.33/m
 ICA 18:                | 379.9/378.4Mh/s | A: 629 R: 2 HW: 0 U: 2.59/m
 ICA 19:                | 379.8/378.1Mh/s | A:1313 R: 2 HW: 4 U: 5.41/m

Apart from a higher U: I've found that the number of hardware errors seems lower... today it's more cold here than every other day of the last week, but the HW: parameter is a lot lower.

I think that ozcoin lets the miner roll the time, see E: at 322%, so I've come to the conclusion that a good deal of HW: errors come from FPGAs hashing during the time that the miner is sending new work and so hashing mostly invalid data (trash in trash out Smiley)

This could be a reason for not having HW: increased by FPGAs since that number is not a real indicator of hardware problems when used with a FPGA.

On the other hand, while do FPGAs keep hashing when a new getwork is sent to them?

And, even more important, of the 87 errors of ICA16, how many of them are real errors and not errors due to hashing of a new, incomplete, getwork?

spiccioli.

are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows

ASIC miners available for purchase

Those who serve best, profit most.
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 06, 2012, 08:01:42 PM
 #1828

are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows

linux, steamboat.

It seem to me that on windows you have make the buffer of the cmd.exe window bigger, going into its properties and making it, for example, 80x50, so that the full list of your boards can be seen inside the window.

In other words, an 80x25 cmd.exe window can only show a few units, you need a bigger window if you have lots of units.

spiccioli.

EDIT: see this for example: https://bitcointalk.org/index.php?topic=28402.msg879120;topicseen#msg879120
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
August 06, 2012, 08:03:42 PM
 #1829

are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows

linux, steamboat.

It seem to me that on windows you have make the buffer of the cmd.exe window bigger, going into its properties and making it, for example, 80x50, so that the full list of your boards can be seen inside the window.

In other words, an 80x25 cmd.exe window can only show a few units, you need a bigger window if you have lots of units.

spiccioli.

With BFGMiner, you could just scroll the unit list with the Up/Down arrow keys...

ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 06, 2012, 08:28:57 PM
 #1830

I don't use any timing options w/ the latest iteration of cgminer, and as long as none of the chips fail it's pretty accurate
For me it's not... Reported hashrate is 700 MH/s whereas U clearly indicated that the "real" performance is only 600 MH/s. Which is what one would expect from the 150 Mhz bitstream.

I'm currently unable to test any other bitstreams because the board is running in a remote location and I don't want to install VirtualBox risking to kill my network connection.

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
August 06, 2012, 09:26:34 PM
 #1831

I don't use any timing options w/ the latest iteration of cgminer, and as long as none of the chips fail it's pretty accurate
For me it's not... Reported hashrate is 700 MH/s whereas U clearly indicated that the "real" performance is only 600 MH/s. Which is what one would expect from the 150 Mhz bitstream.

I'm currently unable to test any other bitstreams because the board is running in a remote location and I don't want to install VirtualBox risking to kill my network connection.
As I mentioned before Smiley

If the device really does hash at the same speed as an Icarus Rev3, it will show correctly.
If it doesn't, then you need to know the timing value for the device (which you can work out with 'long' or 'short') or always run in 'long' or 'short' mode, to get it to show correctly.

The number of shares per piece of work is random, including possibly 0
When a piece of work has no shares, cgminer has to decide when to stop working on it before it finishes so it doesn't end up idle
The Icarus bitstream doesn't send back a message when it finishes, it just goes idle
So the timing determines how long that is and thus how long to wait for an answer and then give up and overwrite it with a new piece of work

How many hashes it did up to the point when it aborted the work is thus estimated based on how fast the device hashes.
So if the timing value is wrong, it will report the MH/s incorrectly

Also, if the timing says it is slower than it really is, it only takes it to be incorrect by ~1% and it will be idle at the end each time a piece of work has no shares - and thus this will reduce the performance and the number of shares it finds

However, if the device hashes slower than an Icarus Rev3, then it wont ever be idle, it will just report the MH/s higher than it really is but with no negative affect on the shares
Though, if it really is aborting work too early, it will have a small negative affect, but usually less than the screen display accuracy ...

FYI: all mining programs that mine on a device with the current Icarus bitstream must perform this 'estimate hash calculation'

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 06, 2012, 10:10:37 PM
 #1832

Thanks. I'm running with icarus-timing=long now. Now MHS av and U are pretty close, even after just 15 minutes.

Which of the values "Hs", "W" and "fullnonce" do I have to pass to icarus-timing to get an accurate reading from the beginning? Found it.

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 06, 2012, 10:21:27 PM
 #1833

are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows

linux, steamboat.

It seem to me that on windows you have make the buffer of the cmd.exe window bigger, going into its properties and making it, for example, 80x50, so that the full list of your boards can be seen inside the window.

In other words, an 80x25 cmd.exe window can only show a few units, you need a bigger window if you have lots of units.

spiccioli.

EDIT: see this for example: https://bitcointalk.org/index.php?topic=28402.msg879120;topicseen#msg879120


it isn't an issue of them working and just not being able to see em, cgminer gives an unexpected error and windows closes it.

ASIC miners available for purchase

Those who serve best, profit most.
testconpastas2
Full Member
***
Offline Offline

Activity: 199



View Profile
August 06, 2012, 10:25:39 PM
 #1834

To open cgminer with ports of an already running board.
for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer  blah blah  -S   20 and 21 again.


I thought that's what you meant. Why would you ever want to do this?

no no i dont wanna do that. it was only a way of "replicate" an error similar to what i get sometimes ( of course doing normal things Wink. and to see if anyone could see any clue in why i'm getting an administrative rights error.

maybe when my fpga is frozen doesnt free any resource and cgminer thinks it is still  busy and show me that error.  it seems weird to me that no body has my error it was all.

Regards.  

Bitmessage: BM-2DAetLWJBKWHZoPbNCgg5z8jwaPpDYWwd4
gpg key id:C6EF5CE3
Keninishna
Hero Member
*****
Offline Offline

Activity: 551



View Profile WWW
August 06, 2012, 11:45:38 PM
 #1835

To open cgminer with ports of an already running board.
for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer  blah blah  -S   20 and 21 again.


I thought that's what you meant. Why would you ever want to do this?

no no i dont wanna do that. it was only a way of "replicate" an error similar to what i get sometimes ( of course doing normal things Wink. and to see if anyone could see any clue in why i'm getting an administrative rights error.

maybe when my fpga is frozen doesnt free any resource and cgminer thinks it is still  busy and show me that error.  it seems weird to me that no body has my error it was all.

Regards.  

Try a diff usb cable, I would get this error with bad usb cables.
testconpastas2
Full Member
***
Offline Offline

Activity: 199



View Profile
August 07, 2012, 11:05:47 AM
 #1836

To open cgminer with ports of an already running board.
for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer  blah blah  -S   20 and 21 again.


I thought that's what you meant. Why would you ever want to do this?

no no i dont wanna do that. it was only a way of "replicate" an error similar to what i get sometimes ( of course doing normal things Wink. and to see if anyone could see any clue in why i'm getting an administrative rights error.

maybe when my fpga is frozen doesnt free any resource and cgminer thinks it is still  busy and show me that error.  it seems weird to me that no body has my error it was all.

Regards.  

Try a diff usb cable, I would get this error with bad usb cables.

my biggest bet is on the usb hub  because the suspicious cable works when i unpluged all the others usb cables from the usb and make a power cycle. but your suggestion will be consider . Thank you.

Bitmessage: BM-2DAetLWJBKWHZoPbNCgg5z8jwaPpDYWwd4
gpg key id:C6EF5CE3
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 07, 2012, 12:02:42 PM
 #1837

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.
Any experiences with pre-S/N-50 boards yet? I cannot test any other bitstream atm because I cannot flip over the dip switch remotely Sad

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 07, 2012, 12:10:16 PM
 #1838

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.
Any experiences with pre-S/N-50 boards yet? I cannot test any other bitstream atm because I cannot flip over the dip switch remotely Sad

Shades,

board #0008, 12 hours, ozco.in, makomk dcmwd2 (the one which tries to workaround cairnsmore issues with clocks) 140 MH/s bitstream.

Code:
ICA  0:                | 371.7/348.3Mh/s | A:3787 R: 5 HW: 1221 U: 3.90/m
 ICA  1:                | 359.7/347.1Mh/s | A:3846 R: 3 HW:  160 U: 3.96/m

I think there is something wrong in the HW: counter for ICA 0, it seems too much for just 12 hours.

spiccioli.
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 07, 2012, 12:20:16 PM
 #1839

@spiccioli have you only tried the 140 mhz bitstream yet? Did you try the non-dcmwd bitstreams before?
I'm running the non-dcmwd 150 mhz without problems on my #26 but I'm wondering if the dcmwd-bitstreams allow clocks higher than 150 mhz on pre-50 boards.

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 07, 2012, 12:30:55 PM
 #1840

@spiccioli have you only tried the 140 mhz bitstream yet? Did you try the non-dcmwd bitstreams before?
I'm running the non-dcmwd 150 mhz without problems on my #26 but I'm wondering if the dcmwd-bitstreams allow clocks higher than 150 mhz on pre-50 boards.

No, I did not try different bistreams on this board.

I was using the old twin_test.bit until yesterday evening.

I hope that the dcmwd ones can run higher on pre-50 boards, but I have not tried them yet. Smiley

spiccioli
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!