Bitcoin Forum
December 10, 2016, 04:59:19 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 [332] 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4826758 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 18, 2012, 02:28:58 PM
 #6621

cut/paste ...

2.7.0
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.7.0a
https://github.com/kanoi/cgminer/downloads

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No Problems so far on my BFL (my 2xGPU+2xIcarus is testing another code change at the moment)

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./configure --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt

I have also added a WinXP cgminer-2.7.0a.exe

This ONLY has BFL + ICA (as below) thus it doesn't need a computer with OpenCL on it
CFLAGS="-O2 -W -Wall" ./configure --enable-icarus --enable-bitforce

You will most likely also need the windowsdlls.zip file there in my downloads since some of my *.dll might be slightly different to ckolivas

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
1481389159
Hero Member
*
Offline Offline

Posts: 1481389159

View Profile Personal Message (Offline)

Ignore
1481389159
Reply with quote  #2

1481389159
Report to moderator
1481389159
Hero Member
*
Offline Offline

Posts: 1481389159

View Profile Personal Message (Offline)

Ignore
1481389159
Reply with quote  #2

1481389159
Report to moderator
1481389159
Hero Member
*
Offline Offline

Posts: 1481389159

View Profile Personal Message (Offline)

Ignore
1481389159
Reply with quote  #2

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

Posts: 1481389159

View Profile Personal Message (Offline)

Ignore
1481389159
Reply with quote  #2

1481389159
Report to moderator
1481389159
Hero Member
*
Offline Offline

Posts: 1481389159

View Profile Personal Message (Offline)

Ignore
1481389159
Reply with quote  #2

1481389159
Report to moderator
1481389159
Hero Member
*
Offline Offline

Posts: 1481389159

View Profile Personal Message (Offline)

Ignore
1481389159
Reply with quote  #2

1481389159
Report to moderator
stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
August 18, 2012, 02:29:40 PM
 #6622

Right off I noticed 2.7.0 is mining on my backup pools even though I'm using failover.  Version 2.6.5 says pool 0 (my primary) is online and it stays on it.  Version 2.7.0 seems to mine all the pools in my list in spite of my pool management strategy being failover.

You are in a maze of twisty little passages, all alike.
farfie
Jr. Member
*
Offline Offline

Activity: 58



View Profile
August 18, 2012, 02:38:28 PM
 #6623

New release - 2.7.0, August 18th 2012

Oh I am very excited about this release. I just fired it up, and immediately I can see a good difference. I think I will finally be able to drop 2.5.0, things are looking splendid. I'll keep you informed. I am so, so happy about this  Grin

Thank you for everything you do ck.
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
August 18, 2012, 03:30:42 PM
 #6624

Right off I noticed 2.7.0 is mining on my backup pools even though I'm using failover.  Version 2.6.5 says pool 0 (my primary) is online and it stays on it.  Version 2.7.0 seems to mine all the pools in my list in spite of my pool management strategy being failover.

Did you specify the --failover-only flag (or set that option some other way)? Default failover leaks work to backup pools and is supposed to.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
August 18, 2012, 04:36:35 PM
 #6625


Did you specify the --failover-only flag (or set that option some other way)? Default failover leaks work to backup pools and is supposed to.

I just copied my command line shortcut over from the previous version.  I never knew about "--failover-only" before.

**later**
That did the trick.  My pool list is abcpool.co, btcguild.com, api.bitcoin.cz, mining.eligius.st.  Without --failover-only it seems to just switch among all 4 as if it were load balancing.  I'm running 200 Mh/s on cable modem.

You are in a maze of twisty little passages, all alike.
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
August 18, 2012, 05:13:32 PM
 #6626

You should probably search the thread on the difference between simple failover and --failover-only; I'll just quickly mention that simple failover gets work from backup pools when the queue runs low where --failover-only only gets work from backup pools when the primary pool fails. This means that --failover-only will probably stop mining for a short time when your primary pool goes down.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
August 18, 2012, 05:22:40 PM
 #6627

I've heard some complaints on abcpool's thread about getting messages "pool not providing work fast enough".  I've seen this error myself occasionally.  I figured maybe abcpool is slower than btcguild so I set up an experiment:

I shortened my list from 4 to 2 so now it's abcpool and btcguild and made abcpool the primary.  I seem to be mining on both roughly equally.
I switched the pools so that btcguild is primary and re-ran.  Same result: roughly equal mining on both pools.

You are in a maze of twisty little passages, all alike.
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
August 18, 2012, 05:31:11 PM
 #6628

any magnitude rig will be kept solidly busy

What is a "magnitude rig"?

New pool strategy: Balance.
--balance           Change multipool strategy from failover to even share balance
This is to differentiate itself from the existing pool strategy, Load balance:
--load-balance      Change multipool strategy from failover to efficiency based balance

Now I finally know what load balance means and understand why I never got balanced shares across pools/servers.  Thanks for the clarification.

the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy.

What exactly is "rolltime"?

Thanks,
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
August 18, 2012, 05:33:47 PM
 #6629

I shortened my list from 4 to 2 so now it's abcpool and btcguild and made abcpool the primary.  I seem to be mining on both roughly equally.
I switched the pools so that btcguild is primary and re-ran.  Same result: roughly equal mining on both pools.

On my setup (debian testing, cgminer compiled from git) my primary pool gets ~9/10 shares and the rest are distributed among the backup pools. This is while the heat is making the router I'm connected to act up, so the network is in generally bad shape from my point of view. IOW, even though some of the getworks get dropped, only about 10% of the shares go to backup pools.
It might be a good idea to investigate whether your setup isn't somehow problematic...

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378


Why is it so damn hot in here?


View Profile
August 18, 2012, 05:37:36 PM
 #6630

Still getting intensity pegging down to -10 on dynamic threads on win 7 x64.  At the same time, when it drops to -10, cgminer starts eating up a whole core of CPU power.   Undecided

This change happened sometime after 2.6.1.  Probably related to to the change in how cgminer handles dynamic intensity that was in 2.6.5, not 100% sure though since my update path was 2.6.1, 2.6.5, 2.7.0.  First saw it in 2.6.5.  Does not happen in 2.6.1.

Any GPU set to dynamic intensity will eventually peg to -10.  Sometimes very shortly after starting, sometimes after running for a while.  I have not yet been able to figure out what the trigger is.

Tested with a clean copy of 2.7.0 with no prefs file after a cold system reboot.

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
farfie
Jr. Member
*
Offline Offline

Activity: 58



View Profile
August 18, 2012, 06:12:26 PM
 #6631

What is a "magnitude rig"?

He means any magnitude (power) of rig (any device which mines bitcoins in our case) will be kept busy with work. Trying to reduce time with no work in other words.
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 18, 2012, 06:30:06 PM
 #6632

New release - 2.7.0, August 18th 2012

First time I've upgraded since 2.5.4 I think.

Everything is working as advertised.

Three things I noticed that I thought I'd mention:

- On both my miners, one with 4 GPUs, and one with 3, initially on startup the highest number one (lowest on the list) shows a massive amount of work done compared to the others, like 10x as much.  They eventually balance out, but on startup it is unbalanced.

- Failover is working much better.  I run two copies of p2pool on two different machines for backup purposes.  The backup would almost always get a very small amount of work from the miners.  Now the backup is getting zero, like its supposed to.

- Just for fun I tried changing the intensity to dynamic.  I normally run it at 8 for my 7970s.  Every GPU I tried it on, cgminer would change it to 7 and it wouldn't move from there.  Wouldn't say D, it would say 7.  I ended up changing them all to 9, which before caused problems, but now it works and increases output.  10 just jacks up CPU usage with no perceptible increase in hash rate.

As usual, great work.  I just send 2 long over due coins your way..

Regards,

M.


MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
Zenitur
Sr. Member
****
Offline Offline

Activity: 368


View Profile
August 18, 2012, 07:56:06 PM
 #6633

Error when CGMINER compiling. Versions 2.3.4-2.3.6. Versions 2.3.1-2.3.3 compiles fine.

...

Thanks for fix of my bug in Cgminer 2.4.0! Forgot to tell this before.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 18, 2012, 09:55:58 PM
 #6634

...

the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy.

What exactly is "rolltime"?

Thanks,
Sam
The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bitcointalk.org/index.php?topic=89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

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
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
August 18, 2012, 11:18:19 PM
 #6635

...

the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy.

What exactly is "rolltime"?

Thanks,
Sam
The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bitcointalk.org/index.php?topic=89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

Very interesting. Thank you for explaining that!

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 18, 2012, 11:29:47 PM
 #6636

New release - 2.7.0, August 18th 2012

First time I've upgraded since 2.5.4 I think.

Everything is working as advertised.

Three things I noticed that I thought I'd mention:

- On both my miners, one with 4 GPUs, and one with 3, initially on startup the highest number one (lowest on the list) shows a massive amount of work done compared to the others, like 10x as much.  They eventually balance out, but on startup it is unbalanced.

- Failover is working much better.  I run two copies of p2pool on two different machines for backup purposes.  The backup would almost always get a very small amount of work from the miners.  Now the backup is getting zero, like its supposed to.

- Just for fun I tried changing the intensity to dynamic.  I normally run it at 8 for my 7970s.  Every GPU I tried it on, cgminer would change it to 7 and it wouldn't move from there.  Wouldn't say D, it would say 7.  I ended up changing them all to 9, which before caused problems, but now it works and increases output.  10 just jacks up CPU usage with no perceptible increase in hash rate.

As usual, great work.  I just send 2 long over due coins your way..
Thanks for feedback and much more for the donation Wink

Startup GPU difference is just luck variance showing up. Perfectly normal.

Glad to hear failover works better.

Dynamic will show the "chosen" current intensity, which for an awesome 7970 works out to about 7. Perfectly normal. (shame it only works properly on linux it seems).

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
farfie
Jr. Member
*
Offline Offline

Activity: 58



View Profile
August 18, 2012, 11:41:10 PM
 #6637

The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bitcointalk.org/index.php?topic=89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

Sort of related, I had a different question - is it possible for you guys to do the opposite of how you will grab long poll from a different pool that you have set up if the primary pool does not support it, so that you could add a local bitcoin client to check for blocks that could possibly find a new one before long poll does?

There's no way I'd be the first to think of this, so I just assumed it's not doable, or perhaps not worth doing? Just curious I guess.

edit: typo
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 19, 2012, 12:14:04 AM
 #6638

...
Sort of related, I had a different question - is it possible for you guys to do the opposite of how you will grab long poll from a different pool that you have set up if the primary pool does not support it, so that you could add a local bitcoin client to check for blocks that could possibly find a new one before long poll does?

There's no way I'd be the first to think of this, so I just assumed it's not doable, or perhaps not worth doing? Just curious I guess.

edit: typo
Bitcoind doesn't have LP in it.
It does have an option to run a command on a block change that you can configure yourself.

I have thought of this before with the API - being able to send a message to the API when a block change occurs, however there is one more thing in an LP that would be missing:
The LP includes work on the new block.

Without this work, the LP is simply telling cgminer to go and do a request for work and thus there is the network delay of waiting for work from the pool.

I will skip certain specific details, to protect the innocent Smiley, but this process would probably be worse than waiting for the LP

... except when LP's are slow ... which has been happening more frequently in the last few months ... but only if the pool would actually return work during it's LP phase (which wouldn't make much sense since it will already be trying to send you work)

However, this could also lead to stalling the miner due to requesting work from the pool and waiting for it, but then simply getting a piece of work for the same 'previous' block if the pool doesn't already know about the new block.

LP design sux and always has since Deepbit came up with the idea (as I have mentioned before as well) - it needs to be faster (e.g. a simple UDP packet TO the miner might perform a lot better)

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
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 19, 2012, 12:33:32 AM
 #6639

Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org


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
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 19, 2012, 12:41:59 AM
 #6640

Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org


Server being relocated.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 [332] 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 ... 830 »
  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!