blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 11, 2015 11:57:09 GMT
Feel free to mosey on over to the other place and ask the TD how come Feb doesn't seem to be any better than December was, when he last promised us a fix early next year. Hmm, or was that the year before?? It's kind of hard to keep track of all these (promised) improvements, isn't it. Getting engaged in the technical improvement programme is part of the frog boiling process. The fact is that up to 50% of accounts may be in error at any one time, and the SM accounting operation is not fit for purpose. I like the post from JTT in another place. Will see how it develops. I see that h*r1997 has joined the fray - great stuff, attaboy!
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 11, 2015 18:56:06 GMT
For 10526 (the 250K A-rated), this time I was actually anticipating extreme Gateway Badness occurring around 3 minutes from lift-off, and it was kind enough to oblige. This got me the rate I wanted, although whether the borrower will share my enthusiasm is another matter. I'm getting a lot of loan offers spat back recently. 10526 accepted and earning interest!
|
|
Steerpike
Member of DD Central
Posts: 1,977 
Likes: 1,687
|
Post by Steerpike on Feb 11, 2015 19:13:02 GMT
For 10526 (the 250K A-rated), this time I was actually anticipating extreme Gateway Badness occurring around 3 minutes from lift-off, and it was kind enough to oblige. This got me the rate I wanted, although whether the borrower will share my enthusiasm is another matter. I'm getting a lot of loan offers spat back recently. 10526 accepted and earning interest! Many unanswered questions on this loan, I wonder why? It seems to have cost them a couple of % on the loan, so unless they were desperate...
|
|
|
|
Post by Deleted on Feb 12, 2015 12:10:29 GMT
I've now had a 20 minute period where I cannot get past a 504, I've cleared caches etc and still no luck.  Given that most deals are now well below my interest targets it is not a real problem, but it is frustrating. Back to the S&P500 and the FTSE then |
|
baldpate
Member of DD Central
Posts: 549
Likes: 407
|
Post by baldpate on Feb 16, 2015 10:11:56 GMT
Yes - it looks like the Saturday run failed part-way through. Sunday distribution didn't happen, presumably as a consequence. Nothing has yet been sorted today.
Incompetent w****rs. Too cheap to implement an alert system, and have somebody on call to deal with the problem (not the first time it's happened).
|
|
|
|
Post by trilby on Feb 16, 2015 16:26:16 GMT
Still missing all of today's payments as far as I can tell and I'm guessing they're unlikely to arrive today at this stage. For what is a failure in the fundamental purpose of their business FC don't seem particularly bothered about it.
|
|
baldpate
Member of DD Central
Posts: 549
Likes: 407
|
Post by baldpate on Feb 17, 2015 9:09:15 GMT
It's now the 17th, and I've yet to receive any repayments due today. So the numpties in the tech department haven't resolved the problem - just let it roll forward.
|
|
|
|
Post by davee39 on Feb 17, 2015 10:20:40 GMT
They are doing something. It looks as though they can only do one manual re-run during the day.
Monday 16th, all payments for 15th run manually
Tuesday 17th, Monday overnight run clears the payments for 16th, I expect payments for the 17th to run during the day (as indicated on the site)
More interesting is why there does not appear to be any out of hours support to pick things up immediately.
|
|
|
|
Post by GSV3MIaC on Feb 17, 2015 14:41:55 GMT
We had this discussion in the other place 2 years ago, when someone tried to persuade me that the repayments run was computationally intensive and required a Cray for 8 hours to complete. Well, only is they are completely screwed up .. I mean worst case there are maybe 500 loans repaying on an ordinary day, with maybe (being generous) 2000 loan parts in each .. gosh that's a million multiply and add operations, with rounding, and transaction reports to write. Could take a reasonably PC several minutes, if we're stuck on rotating media.
A possible problem is, I guess, that the transaction reports are being hit continuously by the need to add/delete all bids ('loan offers') from them every time anything happens anywhere which affects someone's bidding, plus SM sales and purchases. The latter I guess is unavoidable but the bids going in/out/in/out is really rather silly.
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 17, 2015 15:43:07 GMT
Without yours detailed knowledge of systems, GSV, it has seemed to me for some time that the combination of thousands of loans chopped into thousands of parts each, combined with the reverse auction method of sale and setting an average rate from the distribution of all the thousands of individual part rates, with real-time accounting, the daily adjustments of values for every loan part with monthly repayments, and a secondary market also with real time combined accounting, phew - may get to be more than the engines can take sooner rather than later. The error signals resulting from the pathology are obvious, even if we cannot understand the pathology itself.
And it must run 24/7.
It may have been ok to start, but there is every sign that it is not scalable and at least fixed interest rates per loan on the partial board cannot be far off?
Or perhaps a more modular software architecture is all that is needed? Or is the monolithic database the problem?
|
|
|
|
Post by GSV3MIaC on Feb 17, 2015 17:10:37 GMT
I don't know how, exactly, their system is mis-designed, but yes it doesn't seem to scale. There are all sorts of options which would help it (eg dropping the 0.1% rate steps would help LOTS) which FC won't even comment on. There is a 100x to 1000x increase in bids per second when a popular auction nears closing, which is bound to strain any system unless it is massively over capacity for normal operations. Fixed rate would help. Giving all bidders the top rate would help (more incentive to make one 'best offer' bid good and early). 'Shadow bids' ( don't bill transaction reports until after the auction) would help. Throttling maximum bid rates per user (£/min and bids/ min) would help. Right now the answer seems to be 'whole loans' and prayer, plus the system redesign which has been 'coming soon' since forever.
|
|
coop
Member of DD Central
Posts: 714
Likes: 571
|
Post by coop on Feb 18, 2015 11:30:10 GMT
Excellent point on shadow bids ive never understood why they insist on putting them on your statement only for them to disappear when you get outbid...
|
|
sl75
Posts: 2,092
Likes: 1,245
|
Post by sl75 on Feb 18, 2015 12:19:14 GMT
We had this discussion in the other place 2 years ago, when someone tried to persuade me that the repayments run was computationally intensive and required a Cray for 8 hours to complete. Well, only is they are completely screwed up .. I mean worst case there are maybe 500 loans repaying on an ordinary day, with maybe (being generous) 2000 loan parts in each .. gosh that's a million multiply and add operations, with rounding, and transaction reports to write. Could take a reasonably PC several minutes, if we're stuck on rotating media. I don't think that generating the list of transactions to perform is the issue... as you point out, that part can occur in seconds. It's the movement of allocated funds held in the preferential interest of party A so that they're held in the preferential interest of party B (in a manner that is fully auditable and occurs only through confirmed transactions held in a secure log) that would take the time. This almost certainly happens on a system that FC themselves do not directly control other than through an API of a virtual banking system that allows them to create transactions and attempt to apply them to the virtual accounts. Quite possibly, for security reasons, those systems may well be physically located in secure premises to which FC themselves have no physical access... the virtual banking system would be required to be consulted to determine the balances held by each user in the event that FC had a catastrophic systems failure, or their partner bank went bust. It's a totally different set of requirements to the "toy system" that you or I could create on our local PC (using memory backed only by a hard drive), and say "look how much faster than your fancy systems even my normal desktop PC can be". Suppose that you had to have your database fully synced with a copy held on a cloud storage system before you could confirm a transaction, and could only begin a new transaction (or at least a new transaction that "touches" one of the same accounts) once the previous transaction was confirmed... with requirements along those lines, do you still think you could process a million transactions within a few minutes?
|
|
blender
Member of DD Central
Posts: 5,719
Likes: 4,272
|
Post by blender on Feb 18, 2015 15:21:08 GMT
That makes sense. It is presumably a client account, for which the rules are strict. I suppose the physical separation of the loan part database and the client accounting database may be a factor in the creation of all those account errors.
|
|
|
|
Post by GSV3MIaC on Feb 18, 2015 19:23:53 GMT
In which case (SL75) it is even stupider to put all the bids/rejected bids through the same transaction loops as real money needs to go through. Nope I probably couldn't do a million cloud synched transactions in just a few minutes, but I think the average bank, credit card company, or stockbroker could possibly do it in a fraction of the 'all day' that FC takes.
|
|
