is happily being the wheel rather than a rusty old spoke
Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
It's a gift I have too. <g>
10:13:43.
ztest
Funny you'd mention that.
I think we can call the deadlock problem fixed. Hope the same is true of post-numbering?
The new db server is running a pretty steady 22% utilization right now +/-3. I hate to think what the old server would look like right now.
I suspect that once Dave's renumbering processing run tonight, that should be squared away for good.
As Matt reported, the deadlock issues seem to be gone. The culprit was VERY hard to find, but there have been no deadlocks reported by the system since finding/fixing it.
Tell me, if you please, the name of your male parent.
I'm sure you don't need Matt to translate.
test
Think it's getting better.
When I ran a trace on deadlocks this morning (while the system was comparatively idle), it was accumulating something like 10-15 deadlock victims per minute.
I just made the changes we were just discussing and we've had 3 of them in the past 8 minutes.
Still not resolved to my satisfaction, and I hope nothing else is broken as a result, but encouraging and MUCH better.
test
test
I'm sure everyone got the "snapshot isolation error" just now for about 15-20 seconds. I've fixed it and will try again tonight.
ztest
Could you write me one? Can't test it by writing to myself since the system takes me to the message after I submit it. And the subject line in a PM apparently strips out blank lines first.
It could very well be that the new post_info doesn't do that, which should be easy to fix once I can observe it.
test
Default Search AND's all the words. "all good men" would search on "good men". "all" is a noise word. Also, if you use Advanced Search, you can select ANDing or ORing of the words.
All Windoze computers have a noise word list. The one we use is noise.eng. On XP systems, it's in C:\WINDOWS\SYSTEM32. Ours has only a few words added to the default list.
I hope to gain visibility into the catalog one of these days so I can see what other words need to be added.
Once that's done, I'll hopefully have much smaller catalogs. Small enough to make it possible to recombine the catalogs into one again so that date ranges can be used. And, of course, paging through the results.
Truly.
Probably some very basic aspect of SQL Server I've overlooked.
I have a table on the adserver that gets new rows with the first of each type of ad view for the day, and had noticed long ago that a lot of them have no time, where others have a time of a second or so after midnight.
Didn't register that the same mechanism could cause that to happen here. I'll check into it.
Correct. The new db box and SQL 2K5 were pre-requisites. Still have one more to get out of the way. Finding the promised visibility into the catalogs so we can add things like "LOL" to the noise list, getting as much bloat as possible out of the catalogs.
LOL!
I thought for a minute that we had a far worse post_info problem!
EDIT: I did not hit 'preview' first with this post, and when I hit 'submit' it went through without a problem. Does that mean the issue is fixed?
No. It all works flawlessly most of the time. Just a tad over 99% of the time, actually.
But slightly less than 1% failure rate means 200-250 failures per day. Not good.
We're trying to get it to 100% success rate, which should certainly be do-able. It was on the old system using the old post_info, although with that one we were getting deadlock errors. No idea how many.
I'm going to have to put some thought into doing this as two separate procs. One that only does the insert and another to do the other stuff. The whole transaction, as-is, is pretty big and probably takes too long. The insert is the most important part and probably should be by itself so it's less likely to be part of a failed transaction.
Then another to do all the necessary updates.
At face value, sounds like it'd reduce collisions, though I'm sure it's not the complete solution. Still need try/catch and need to determine and set the isolation level that's best for our scenario.
Initially just makes things more puzzling, though it should be another clue to what's going on.
The message id field here is an identity field, so the only way I can think of that *might* cause skipping is two concurrent writes with one of them failing. Maybe. I would think the successful one would grab the number and the failed one wouldn't be able to.
I'm definitely going to have to use try/catch in the post_info proc and at least log the errors to see what's going on. Though the main idea is to prevent the errors from happening in the first place, have to identify the errors first, though I'm nearly 100% positive that locking/concurrency issues are preventing the message insertion from happening. At times. Looking like about 1% of the time, which is way too high.
Edit: I put the TRAN wrapping back around the message insertion proc, which I'm pretty sure will at least prevent the msg number gaps. I think those are getting caused by the insert failing but the updates, including board msg count, which is used for intra-board numbering, aren't failing. With the TRAN wrapper, one item fails, they all fail and are rolled back.
Though I do need to check to make sure this version of SQL will automatically roll back on failure and I don't need to explicitly tell it to do so.
Actually, once I'm warm and fuzzy about the condition of the engine itself (the mechanicals, including a compression test which the service advisor said would be done, but wasn't done), the next step will be to get the handling as good as it can get, then I'll start going nuts with the engine. Including tuning it on the dyno.
The shop that sponsors kcsubaru.com recommends strictly Cobb stuff, and the dealership said that Cobb started out with Subaru, went his own way, and is being brought back in to Subaru.
However, as I understand it, Cobb tuning is accomplished via reflashing the PROM. Which is a problem for me. If I end up turning this into a 850-horse beast, I'd like to be able to detune it to something more reasonable for rain use, and something pretty tame for when anyone else drives the car (wife, son, valet, etc).
The PROM can only handle about 100 flashes.
Also, I'm seeing nothing from Cobb or Cobb-compatible that'll give any kind of display. I'd like not only a display, but the ability to select different maps from within the car. Much like the Edge w/Attitude I use in my truck.
So, I want something that uses a piggy-back computer and has a display screen that not only gives me tons of valuable info in realtime (as well as storing it for later replay), but also lets me make adjustments on the fly.
I think TurboXS might offer what I'm looking for.
Oh, and the Scoob specialist that brings cars by the trailer-load to Imagine Auto to tune on their dyno refuses to work with Cobb cars.
So, I'm casually shopping for engine management stuff, but not too serious about it yet. I'm unsure of the mechanical condition of the engine itself. And though the pricetag is a bit steep for a major part of a toy, I think the peace of mind and the much larger envelope might be worth it to simply replace this engine with a Cosworth-built one, which I think is good for 8500 rpm. And if mine's in good enough condition, I'm sure I could sell it for enough to offset a large part of the Cosie's cost.
With the problems I'm seeing with stock Subaru engines that are being largely tweaked externally and through software, this really might be the way to go for something whose life is going to be much like that of a rented mule.
But, aside from making sure the engine is working correctly, my focus will start with suspension and braking. And the braking's pretty good with the Raybestos ST41 pads in front, except for the vibration that I strongly suspect is caused by front wheel bearings not pre-loaded enough or some other component (ball-joint, steering rack) not tight enough.
A couple items on the to-do list for this weekend are to check how much torque is on the axle-end nut through each hub, and to dismount a tire each from the stock BBS wheels and the new ASA's and weigh them.
The dealership actually tried to tell me the reason I'm getting pulled by an identical car on the straights is that my ASA wheels are a lot heavier than the BBS wheels.
I don't think there's that much weight difference, and any weight penalty there might be, I'd be paying more in the braking zones than in acceleration.
Well, those are on the to-do list after helping my son with his motorcycle engine. Yamaha XS650 that we're finally ready to put together as a 750 with a pretty aggressive cam. That and buying a power washer and cleaning the backhoe, especially the battery box. It won't start, and I suspect that the batteries being completely surrounded in mud is preventing them from getting much of a charge and letting much juice make it to the starter. Figure I can do that while he's cleaning and bead-blasting engine covers and parts, then I'll have to do the engine assembly.
Too bad his tank and seat aren't ready yet. They're out getting painted. Would very much love to go for a test-ride on this bike when we get the engine done. Although I have no idea how much of the rest of the bike is done. I know he brought the frame with him, but have not idea if anything's actually on the frame and am pretty sure he's counting on me to do all the wiring.
Should be a really cool bike, btw. He's going very minimalist with it, including the frame being powder-coated the same aluminum color of the engine, and we're going to try to make sure no wires are visible anywhere.
Shoot! You're right! Not only was I thinking of the wrong ideal number, I was backwards on my thinking and thought the mixture was getting leaner at higher revs.
I'll have to look at the graph again. Supposedly (anecdotally) these things are supposed to practically dump fuel into the cylinders when they're at full boost.
Note, these figures are at the wheels. I'm told you add 20% in an AWD car to get crankshaft figures.
Remember the white WRX I brought with me to RA and recently traded in on the STi?
I was at the dealership today (no resolution to problems) and that thing was STILL there.
They're asking $22k for it. Yikes! It's a 2004 with 25k miles on it and I paid $23.7k for it new!
But it gets worse.
Poor thing has some tacky black "swoopy" graphics on it now. I took pics with my cellphone and will try to post them when I can.
Also went to Imagine Auto to put the car on the dyno. Dunno if I mentioned that it's WAY down on power compared to Gary's equally stock 2005 STi. Sheridan took my car out for a session at HPT in Gary's run-group and Gary even held up so Sheridan could catch up, then ran away from him on the straights.
I couldn't believe it! Then Gary offered to let me drive his car, which I did. Two laps later I pulled in, feeling sick about mine. His car pulls in 4th like mine in 3rd.
However, the dyno says mine's pretty close to making what Subaru says it should, assuming you can add 20% to the wheel numbers to account for AWD drivetrain losses. Peaked right at 250 horses at the wheels at 6k.
The dyno might've pointed out a major problem, though. It's supposed to make 300 lbs of torque at 4k rpm. And that's supposed to be where peak torque lives. Not so in my car's case, and that's the area where his car is killing mine.
At 4k rpm mine's making about 220 lbs at the wheels and keeps climbing until it peaks at about 240 lbs from 4700 to about 5300, where it starts falling off.
Isn't the ideal air/fuel ratio something like 14.7 to 1? Mine does that near the bottom of the graph (about 2200 RPM) but by the time it reaches 3k, it's down to about 13.5 and drops steeply to about 11.2 at 4k and barely above 10 at 6800 rpm. Those numbers look kinda scary.
And my fuel economy has gotten "too good". 22 mpg, driving it like I borrowed it from you and you said "Have fun!" <g>
Anyone I've talked to about it has said they can't get 22 mpg babying theirs.
Will make arrangements to get Gary's car on the same dyno as soon as possible. After he blows my doors off at MAM next weekend.
I think that's about what the lowering "dogbone" cost for my Kaw KLR650. It helped quite a bit, but I never could get the bike to where it was low enough for me. It starts out with a VERY tall seat height, though.
I think it's anything that interacts with Active-X. Meaning any IE plug-in.
That actually confuses the issue even more! Hopefully unrelated.
Okay, I know you're referring to http://www.investorshub.com/boards/read_msg.asp?message_id=13323236 but I can't find any view that doesn't show the "who wrote msg#" bit.
Can you give me a URL that has that bit missing from the screen?
Whew!
I haven't looked into what different views yield different results. Only 4 views that I know of, so shouldn't take too long to check once I find the message.
Actually, it looks like some of the folks from the ADVFN message board might start an "ADVFN expatriates" board here. Should be interesting. Especially since they seem to think we Yanks have no sense of humor. Oops. Humour.
Actually, we don't. Most of the best humour, IMO, comes from the great white north anyway, eh.
Ummmmm.... Dave?
If you get a chance, could you check the message table and see if the replied-to post number is referenced by message-id or message-number? And really hope it's the former!!!
Check out the bolds below.
susie, once again..
Posted by: wickw50
In reply to: Susie924 who wrote msg# 73504 Date:9/14/2006 7:54:13 PM
Post #of 73509
susie, ok I accessed it differently and look at it now..
Posted by: Sentinel
In reply to: rvd who wrote msg# 21419 Date:9/14/2006 7:20:03 PM
Post #of 21427
I sincerely hope that is what they are doing.
And from accessing favorites..
China Direct Trading Corp. (CHDT)
Posted by: Sentinel
In reply to: rvd who wrote oops! No msg#
Date: 9/14/2006 7:20:03 PM
Post # of 21422
I sincerely hope that is what they are doing.
Wick
-------------------------------------------------------
I have to run my Scoob to the dealership right now, but when I get back I'll look into this.
As our resident half-programmer mentioned, it's been brought up before and at our scale would be an awful lot of work for the server. It's already a lot of work for the server that it's having to do this at the board level. At the post level? Fuhgedaboudit.
Especially since we'd have to make it most *unique* reads to circumvent most of the manipulation that already occurs with board reads.
However, as someone else pointed out, we do have a bigger/better server now. It'd be a comparatively easy (but still low priority) thing to add so we can quantify just how big the workload would be, and set it up so it can easily be manually or automatically shut off if server utilization gets too high.
(still thinking out loud)
The new server is running at about 15% of its capacity during market hours where the old one was more like 60% with too-frequent spikes much higher. So, the horsepower definitely exists. Today. I have zero doubt it could handle a workload like that. But would make it sooner that we'd need something more powerful again.
After we've stabilized the current server (there are concurrency, locking, and isolation issues still to be addressed) and gotten some other important projects done, we'll give it a try and see what happens.
On a side note, though Moore's law has been dead for a while, a separate law whose name escapes me is still in full effect.
Less than 2 weeks after buying this server, I got an email from Dell that a machine that was way outside the range I'm willing to pay for a computer is on sale.
Had we waited, we could've gotten roughly 250% more power for 50% more money. AARRGGHH!! We paid around $10k for a box with a couple of dual-core Xeon 3.0's. For just over $15k, we can now get one with FOUR dual-core 3.4's! Previously, the price jump from 2 to 4 processors had been enormous!
In the not-too-distant future, I'll be replacing SI's box, though it's seriously underworked. It's old and the case is ridiculously large. We're planning to convert to exclusively rack-mountable machines (in a Dell cabinet and using proper rails instead of shelves), so all the tower machines will get removed/replaced and brought to the office as development boxes (I already dib the adserver as my personal desktop machine, so back off, Matt and Dave).
I can probably make a good case for getting the quad-processor box, moving iHub's db to it, and moving iHub's new db box to the SI db role. Then we'd have the future very out-gunned on both sites, as well as having enough power on each db box to step in to db-serve BOTH sites if one of the boxes breaks.
So, (end of essay-length thinking out loud) we'll try what you suggest when we get a chance and when we get more important things taken care of, and see how it works out. The cost of trying it would be very low in terms of geek time. And we'll be able to quantify the cost in computing horsepower to see if it's worth it.
But the fact that you see just such a feature (among other features) on small sites running off-the-shelf software is one of the reasons they can't ever become big sites. Some things simply aren't do-able at our scale at a reasonable economic and horsepower cost.
Quick. Guess the hair color of the gal with whom you're having this exchange regarding something technical. <g>
Actually, can't diss her too much on this one. What you're pointing out is very subtle, but looks like a problem. I'll read on through to see if it's been addressed.
Did you select "Update" after making the change?
I had exactly the same problem (except for the crashing) and that's what fixed it for me.
The problem with message numbers in some boards being larger than what's shown as the total number of messages in those boards should now be fixed, but only temporarily.
Turned out the problem was skipped message numbers. Spent most of the day running programs to renumber boards where that was a problem.
Surprisingly, on the vast majority of them, the first skipped message number was quite old.
But I'm sure the problem will continue to resurface until I can get post_info completely fixed so it never misses a beat. No idea how well it behaved today.